Backuplösung

[Pixelpaule]

Wobei es bei mir immer noch nicht ganz richtig sein kann?! Denn ich habe ja als Source für das Backup-Script den Ordner unRaid Backup angegeben: Hier rein packt mir das Script jetzt als aller erste Ebene die Ordner mit Datum... In diesen Ordner sind dann jeweils getrennt die Shares. Ich erkenne ja so nicht in welchem Datums-Ordner dann welcher Share ist?! Bei mir fehlt demnach doch der "erste" Share Ordner der durch das Script angelegt wird. Meine Struktur ist aktuell demnach:

 

/unRaid_Backup (Hauptordner für das Script)/Datum/Share

 

Im Script ist folgendes angelegt:

source_paths=(
    "/volume1/unRaid_Source/Datenstube"
    "/volume1/unRaid_Source/Cloud"
)
backup_path="/volume1/unRaid_Backup"

 

[monarc]

Magst du mal dein Skript teilen welches du auf dem Synology nutzt, da hast du doch sicherlich die ein oder andere Anpassung gemacht. Kann es dann bei Gelegenheit mal mit meinem vergleichen.

[Pixelpaule]

An dem Script habe ich nichts angepasst. Nur die Ordner eben.

backup_unraid.zip

 

Mal eine weitere Frage...: Wenn man mit einem Backuptool (HyperBackup - Synology oder Duplicati) die Backups, die mit dem rsync Script erstellt wurden, in die Cloud sichert, gehen die Hardlinks dann verloren?

 

@monarc @mgutt

Nachtrag: 07.08.:

Wenn ich das Script auf meinem unRaid Server ausführe legt er alles sauber an.
.../SHARES/Sharename/Datum/Sharename/...

 

Edited August 7, 2021 by Pixelpaule

[mgutt]

22 hours ago, Pixelpaule said:

Wenn man mit einem Backuptool (HyperBackup - Synology oder Duplicati) die Backups, die mit dem rsync Script erstellt wurden, in die Cloud sichert, gehen die Hardlinks dann verloren?

Ja. Das liegt daran, dass Clouds einen mit abgespecktem Zugriff gängeln. Aus dem Grund ist meine "Cloud" ein unRAID Server an einem externen Standort. In deinem Fall könnte es auch die Syno sein.

 

Als Workaround für dein Problem gingen zwei Scripte mit dem gewünschten Unterordner als Ziel. 

[Pixelpaule]

On 8/7/2021 at 10:10 AM, mgutt said:

Ja. Das liegt daran, dass Clouds einen mit abgespecktem Zugriff gängeln. Aus dem Grund ist meine "Cloud" ein unRAID Server an einem externen Standort. In deinem Fall könnte es auch die Syno sein.

 

@mgutt Du sicherst sonst nichts mehr in die Cloud zu einem Anbieter? Alles nur auf den externen unRaid Server?

 

Ich werde das jetzt auch so machen, dass ich nur die wichtigsten Daten noch ein mal zusätzlich in die Cloud sichere und den Rest auf meine Synology und den externen unRaid Server. Das Cloud Backup werde ich dann mit Duplicati machen und parallel erst mal noch mit HyperBackup, bis ich HyperBackup absetze. 

 

On 8/7/2021 at 10:10 AM, mgutt said:

Als Workaround für dein Problem gingen zwei Scripte mit dem gewünschten Unterordner als Ziel. 

 

Ich wollte mal testen was passiert, wenn ich die Ordner auf der Synology in einem Unterordner "/mnt/user/" einbinde... Ansonsten hatte ich mir auch schon überlegt einzelne Scripte für die Shares anzulegen.

[mgutt]

1 hour ago, Pixelpaule said:

Du sicherst sonst nichts mehr in die Cloud zu einem Anbieter?

Doch, aber nur die Daten mit der höchsten Priorität und diese auch nur verschlüsselt als 1:1 Sync, da die Cloud selbst ja über eine Versionierung verfügt, so dass gelöschte Dateien über den Papierkorb wiederherstellbar wären.

 

Allerdings könnte ein Angreifer, der Unraid kontrolliert, dann immer noch hingehen und die Cloud x-mal überschreiben, um eine Wiederherstellung zu verhindern. Da kommt es darauf an welche Schutzmechanismen die Cloud besitzt oder ob die Cloud über eine Backup-Funktion verfügt, die über einen anderen Account oder nur über 2FA erreichbar ist.

 

Hier meinte zB jemand, dass er versucht hat eine ZIP-Datei auf seinem Google Drive 201x zu überschreiben und das schlug dann fehl. Wenn das generell so ist, wäre das Backup in der Cloud ja sicher, außer man hat die Cloud über User + Passwort eingebunden und diese hat kein 2FA.

 

Bei Nextcloud wäre es zB so, dass User + Passwort bekannt wäre. Aber das wäre vom Prinzip sogar egal, denn dort werden die Versionen bei Überschreitung von 50% des freien Speicherplatzes einfach automatisch gelöscht. Ein Angreifer muss also hier nur dauerhaft die Cloud überschreiben und irgendwann sind die Original-Dateien dann weg. Da hilft dann ja kein 2FA, weil die Cloud über deren Schnittstelle/App ja ohne 2FA erreichbar ist.

 

Ich weiß auch gar nicht, ob man bei Nextcloud über die Schnittstelle nicht sogar den Papierkorb und die Versionen löschen könnte:

https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/trashbin.html

https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/versions.html

 

Vermutlich wäre die beste Variante, wenn man zwei Accounts hat und die Ordner in die man sichert von einem anderen Account sind, der einem ausschließlich Erstellrechte einräumt:

 

Ohne Bearbeitung und Löschen, könnte der Angreifer die Dateien dann nicht löschen oder überschreiben. Allerdings muss man dann überlegen wie man mit aktualisierten oder gelöschten Dateien umgeht. Die einfachste Methode wäre mehrere 1:1 Backups zu erstellen und das Löschen veralteter Backups nur manuell auszuführen (2FA).

 

Oder man geht hin und lässt geänderte Dateien in ein separates Verzeichnis kopieren. Das geht mit rsync zB mit compare-dest. Ich weiß allerdings nicht ob das auch gelöschte Dateien abdeckt. Müsste man mal testen. Oder man nutzt dafür einen separaten Befehl mit backup-dir?!

 

Eine Cloud ist jeden Fall nichts, was "einfach so" sicher für Backups ist.

 

 

[Pixelpaule]

On 8/6/2021 at 11:10 AM, monarc said:

Magst du mal dein Skript teilen welches du auf dem Synology nutzt, da hast du doch sicherlich die ein oder andere Anpassung gemacht. Kann es dann bei Gelegenheit mal mit meinem vergleichen.

 

@monarc Hast du die Synology über unRaid eingebunden oder unRaid in der Synology? Wenn ich die Synology über unassigned devices einbinde, werden die Ordner korrekt angelegt. Wie hast du das Script denn bei dir eingebunden? Auch über den Aufgabenplaner? Egal welche Einstellungen ich wähle, es erstellt nicht wie gewünscht die Ordner.

Edited August 9, 2021 by Pixelpaule

[Pixelpaule]

On 8/7/2021 at 10:10 AM, mgutt said:

Als Workaround für dein Problem gingen zwei Scripte mit dem gewünschten Unterordner als Ziel. 

 

Also irgendwie bekomme ich das nicht richtig ans Laufen. Wenn ich zwei Scripte anlege, dann passiert genau das Gleiche da er erst das eine Script durchläuft und dann das zweite. Beide male wird dann ein neuer Ordner mit Datum angelegt. Die Backups der Shares liegen also nicht zusammen in einem Datumsordner.

[mgutt]

1 hour ago, Pixelpaule said:

Die Backups der Shares liegen also nicht zusammen in einem Datumsordner.

Dann haben wir denke ich aneinander vorbei gesprochen. Normal ist es so:

Backups/Sharename1/20120801_040000/Sharename1

Backups/Sharename2/20120801_040000/Sharename2

 

Der letzte Unterordner ist dabei wie gesagt eigentlich überflüssig, aber wegen dem einfacheren Copy & Paste fand ich das irgendwie praktischer (und ich bin wie gesagt noch unsicher wegen der Position der Log-Datei).

 

Du möchtest es dagegen so haben oder?

Backups/20120801_040000/Sharename1

Backups/20120801_040000/Sharename2

 

Das Problem hierbei ist, dass es mehr als ein Backup pro Tag geben kann und der Ordner einen sekundengenauen Namen trägt ("_044022" = 04:40:22 Uhr nachts) und jeder Quellordner ein eigenes Script mit eigenen Aufbewahrungsregeln haben kann. Also vielleicht sicherst du zB den Share "domains" nur 1x pro Woche und den Share "appdata" 2x pro Tag und deinen PC halbstündlich und alles soll unterschiedlich lange aufbewahrt werden. Behalte das nun mal im Hinterkopf und nun stell dir vor du siehst dein Backup-Verzeichnis:

 

Wo ist nun das vorletzte Backup von domains drin? Nicht jeder hat einen Datei-Explorer mit Verzeichnisbaum.

 

Das einzige was ich mir in Zukunft tatsächlich vorstellen kann, ist dass man es so macht:

Backups/Sharename1/20120801_040000

Backups/Sharename2/20120801_040000

 

 

[Rockikone]

Ich hätte hier nur mal eine kurze Verständnisfrage bzgl Synology und dem Script von mgutt.

Ich selbst habe eine Synology 415+. Diese nehme ich auch zur Sicherung von meinen Unraid Shares.

 

Ich benutze jedoch nicht das Script sondern das Synology Programm Active BackUP for Business.

Die Sicherung erfolgt als Dateiserversicherung per Rsync over SSH. Ich sehe den Vorteil insbesondere, dass ich keinerlei Share in Unraid einhängen muss und mir keine Gedanken bzgl Ramsomware machen muss, da keine Laufwerksverbindung (SMB NFS) besteht.

Das Progamm sichert mir alle Shares sauber weg (Root Zugang) und ich kann alles sauber über eine KlickiBunti Oberfläche einstellen.

 

Welchen Vorteil hat hier das Script?

 

Grüße aus Bayern

[Pixelpaule]

2 hours ago, mgutt said:

Dann haben wir denke ich aneinander vorbei gesprochen.

Das kann sein  

Wobei ich es so haben will wie es dein Script standardmäßig eigentlich macht. Allerdings ist es bei mir leider anders, warum weiß ich eben nicht. Bei mir ist es so, dass die Backup Ordner mit Datum als erstes angelegt werden und innerhalb dieser dann die Sharenamen sind.

 

Aktuell mein Fall: Backups/20120801_040000/Sharename1

 

Ich möchte aber:

Backups/Sharename1/20120801_040000/Sharename1

 

Was aber leider nicht klappt.

 

 

@Rockikone Wenn doch von der Synology mit root auf unRaid zugegriffen wird, ist das nicht auch "gefährlich" wenn die Synology kompromittiert werden würde? Wäre hier SMB mit extra angelegtem User auf unRaid nicht sicherer?

 

An sich finde ich die Lösung aber spannend, weil sie genau das macht was ich suche... Über das Active Backup for Buisness Portal lassen sich die Sicherungen auch bequem wiederherstellen. 

 

Edited August 17, 2021 by Pixelpaule

[ich777]

37 minutes ago, Rockikone said:

Ich benutze jedoch nicht das Script sondern das Synology Programm Active BackUP for Business.

Die Sicherung erfolgt als Dateiserversicherung per Rsync over SSH.

Kostet das was?

 

Wenn ja wäre evtl luckyBackup eine Gratis option, ist praktisch das gleich als Docker mit noVMC GUI (rsync als backend und natürlich auch über SSH, mit Cron und Versionsverlauf wenn gewünscht)

Läuft praktisch überall, Synology, unRAID usw. die ARM versionen vom Container hab ich aber auf Eis gelegt.

[ich777]

49 minutes ago, Pixelpaule said:

@Rockikone Wenn doch von der Synology mit root auf unRaid zugegriffen wird, ist das nicht auch "gefährlich" wenn die Synology kompromittiert werden würde?

Ja, aber warum sollte die kompromitiert werden?

Die dient nur als Backup meines Wissens nach in @Rockikone's Fall und auf der läuft sonst nichts anderes.

 

Ich hab das genau so mit luckyBackup (mit KlickiBunti Oberfläche - gefällt mir der Ausdruck von @Rockikone ) auf einem dedizierten Backup Server der nur einmal im Monat eingeschaltet ist.

Wenn der Backup Server wirklich an einem anderen Ort steht dann könnte man eine Server zu Server verbindung mittels Wireguard machen damit man synchronisieren kann.

[Pixelpaule]

20 minutes ago, ich777 said:

Ja, aber warum sollte die kompromitiert werden?

Die dient nur als Backup meines Wissens nach in @Rockikone's Fall und auf der läuft sonst nichts anderes.

 

Puh, ja sicher kann man sich ja nie sein... bin einfach immer etwas skeptisch den root User dauerhaft in Software zu nutzen und zu speichern...

 

20 minutes ago, ich777 said:

Wenn der Backup Server wirklich an einem anderen Ort steht dann könnte man eine Server zu Server verbindung mittels Wireguard machen damit man synchronisieren kann.

 

Wie sieht's denn damit aus? @mgutt hat hier geschrieben das Wireguard auf unRaid Basis die unsicherstes Variante einer VPN Verbindung wäre: 

 

Edited August 17, 2021 by Pixelpaule

[ich777]

16 minutes ago, Pixelpaule said:

Puh, ja sicher kann man sich ja nie sein... bin einfach immer etwas skeptisch den root User dauerhaft in Software zu nutzen und zu speichern...

Naja in meinem Fall ist der BackupServer vom Netzwerk und Strom getrennt und wird nur zum Syncen angeschaltet und angeschlossen und dort läuft wirklich nur Gotify drauf und luckyBackup.

 

luckyBackup beispielsweise läuft by default zB nie als root user bzw. hast du die option im Docker template den container als root laufen zu lassen.

Aus dem einfachen Grund wenn du von deinem unRAID System zB den /boot Ordner sichern willst auf ein anderes System, braucht der Container nämlich root rechte zum lesen, anders kannst du den Ordner sonst nicht sichern.

 

Du hättest die Möglichkeit einen 2. Benutzer anzulegen und dem auf alles Leserechte gibst wenn du wirklich so skeptisch bist aber das würd ich wieder nicht machen.

 

Ich find luckyBackup ein wenig einfacher weil KlickiBunti Oberfläche. :D

Kannst dich dann auch per Mail benachrichtigen lassen wenn das Backup fertig ist oder einen bash Befehl ausführen lassen (Pushover, Gotify,...).

 

Vergiss nicht man kann mit SSH von oder auf einen Server syncen, ich seh da aber in beide Richtungen aber kein Problem.

Ich persönlich find es komfortabler luckyBackup auf dem System laufen zu lassen auf das ich auch synchronisieren will.

[mgutt]

1 hour ago, Pixelpaule said:

Was aber leider nicht klappt.

Genau das sollte ja gehen, wenn du zwei Scripte nimmst und den Zielpfad entsprechend verlängerst. Also nicht beide auf "/Backup" zielen lassen, sondern ein Script auf "/Backup/Sharename1" und das andere auf "/Backup/Sharename2". Oder hattest du das schon versucht? Wenn nein, dann probiere mal "Backup/einenAndereNamen", falls mein Script warum auch immer den Sharenamen ersetzen sollte.

 

1 hour ago, Rockikone said:

mir keine Gedanken bzgl Ramsomware machen muss, da keine Laufwerksverbindung (SMB NFS) besteht.

Das Progamm sichert mir alle Shares sauber weg (Root Zugang) und ich kann alles sauber über eine KlickiBunti Oberfläche einstellen.

Wenn deine Syno eine Sicherheitslücke hat, ist alles weg, denn die Syno hat ja Root Zugriff auf den Unraid Server. Wer schreiben kann, kann schreiben. Und das gilt es zu vermeiden, wenn man sicher gegen Ransomware sein möchte. Also wenn solltest du Active Backup mit einem rein lesenden Zugriff kombinieren.

 

1 hour ago, Rockikone said:

Welchen Vorteil hat hier das Script?

Das Script erstellt völlig transparente Backups und braucht daher keine Software zur Wiederherstellung. Jeder Ordner ist ein Vollbackup und durch Hardlinks trotzdem inkrementell. Man nimmt also den Ordner von vor 3 Tagen und es sind 1:1 alle Dateien von der Quelle drin. Bei Active Backup, was ich früher auch gerne eingesetzt habe, gibt es auch inkrementelle Backups, aber die erfordern den Erhalt des gesamten Backup-Verlaufs, da jedes Folge-Backup auf das vorherige aufbaut. Ohne Active Backup kann man also nichts wiederherstellen. Das ist der Hauptunterschied zwischen den beiden Konzepten.

 

Eine Absicherung gegen Ransomware bietet mein Script übrigens genauso wenig wie Active Backup. Diese Absicherung kommt erst dadurch zu Stande, in dem man es intelligent einsetzt. Also wie schon gesagt, die Quelle ausschließlich lesend mountet.

 

1 hour ago, ich777 said:

Kostet das was?

Jein, man braucht ein teureres Syno Modell. Die J-Modelle können das zB nicht:

https://www.synology.com/de-de/dsm/packages/ActiveBackup

 

Außerdem geht es nur, wenn man BTRFS im RAID verwendet.

[ich777]

2 minutes ago, mgutt said:

Jein, man braucht ein teureres Syno Modell. Die J-Modelle können das zB nicht:

https://www.synology.com/de-de/dsm/packages/ActiveBackup

 

Außerdem geht es nur, wenn man BTRFS im RAID verwendet.

Ah alles klar, danke!

 

Dann wäre hier luckyBackup für x86_64 basierende Systeme die Docker unterstützen eine alternative.

Wie gesagt hab die ARM versionen begraben da ich zu wenig downloads drauf hatte...

[Pixelpaule]

41 minutes ago, mgutt said:

Genau das sollte ja gehen, wenn du zwei Scripte nimmst und den Zielpfad entsprechend verlängerst.

Ja, okay... Der Einfall kam mir dann auch noch! Da haben wir dann tatsächlich kurz aneinander vorbeigeredet.

 

41 minutes ago, mgutt said:

Wenn deine Syno eine Sicherheitslücke hat, ist alles weg, denn die Syno hat ja Root Zugriff auf den Unraid Server.

Genau das sind meine Gedanken die ich habe, bezüglich root Zugriff von Synology auf unRaid.

Edited August 17, 2021 by Pixelpaule

[ich777]

2 minutes ago, Pixelpaule said:

Genau das sind meine Gedanken die ich habe, bezüglich root Zugriff von Synology auf unRaid.

Aber wie oben erwähnt könnte man auch von unRAID auf die Synology syncen, dann wäre dieses Problem gelöst...

[Pixelpaule]

7 minutes ago, ich777 said:

Aber wie oben erwähnt könnte man auch von unRAID auf die Synology syncen, dann wäre dieses Problem gelöst...

Die Unix-Extensions sind laut Synology Support noch experimentell, weshalb nicht empfohlen wird diese im produktiv Einsatz zu aktivieren. Deshalb haben @monarc und ich das ganze andersherum eingerichtet. 

 

[mgutt]

37 minutes ago, ich777 said:

Aber wie oben erwähnt könnte man auch von unRAID auf die Synology syncen, dann wäre dieses Problem gelöst...

Dann hätte Unraid aber wieder Schreibrechte auf der Syno und bei einer Sicherheitslücke könnte der Angreifer das Backup auf der Syno platt machen.

[ich777]

30 minutes ago, mgutt said:

Dann hätte Unraid aber wieder Schreibrechte auf der Syno und bei einer Sicherheitslücke könnte der Angreifer das Backup auf der Syno platt machen.

Dann leg doch einen Benutzer auf der Synology an der nur in einem gewissen Ordner lese/schreibrechte hat.

 

Verstehe das Problem nicht...

 

Man kann sich immer alles gut oder schlecht reden, übrigens luckyBackup würd auch das syncen über SMB usw. unterstützen...

[mgutt]

5 minutes ago, ich777 said:

Dann leg doch einen Benutzer auf der Synology an der nur in einem gewissen Ordner lese/schreibrechte hat.

Der Angreifer hat dann zwar nur in diesem einen Ordner Schreibrechte, aber da liegen ja die Backups drin. Verschlüsseln/löschen kann er sie dann ja trotzdem.

 

8 minutes ago, ich777 said:

Man kann sich immer alles gut oder schlecht reden

Erlebe du mal eine Ransomware-Attacke. Dann reden wir weiter.

[ich777]

13 minutes ago, mgutt said:

Der Angreifer hat dann zwar nur in diesem einen Ordner Schreibrechte, aber da liegen ja die Backups drin. Verschlüsseln/löschen kann er sie dann ja trotzdem.

...und was bietest du für eine Lösung an?

 

13 minutes ago, mgutt said:

Erlebe du mal eine Ransomware-Attacke. Dann reden wir weiter.

Das war nicht auf Ransomware bezogen, weiß nicht wie du da drauf kommst...

[mgutt]

12 minutes ago, ich777 said:

...und was bietest du für eine Lösung an?

LuckyBackup oder was auch immer auf dem Ziel installieren und die Dateien ausschließlich lesend abholen. Um Quelle und Ziel zu vernichten, müssten dann erstmal beide gehackt werden.