[gelöst] Zusätzlicher Backup-Server für das NAS

[hobbyadmin]

Wenn die Zeit allerdings auch dafür noch nicht reicht, bin ich Schach matt : )

Nicht unbedingt, du könntest (genügend Speicherplatz vorausgesetzt) Unterordner mit dem jeweiligen Datum einrichten und deinen Server in den Ordner mit dem aktuellen Datum sichern lassen.

Über rsync sicherst du dann den aktuellen Ordner. Nach 24h startet dann dein Server ein neues Backup aber rsync bleibt davon unberührt, weil es noch den Ordner des Vortages sichert. Damit bekommst du dann vollständige Sicherungen hin, aber schiebst gleichzeitig eine größer werdende Welle von noch ausstehenden Sicherungen vor dir her.

Bleibt die Frage, ob wirklich jeden Tag 1,5TB an Daten gesichert werden müssen oder ob man das Konzept anpassen kann.

Naja, erstmal schauen was deine Änderungen bringen.

Den Schalter --partial habe ich auch gefunden. Ich habe jedoch -P genommen. Da ist doch --partial und --progress mit drin, oder?

Ja.

Das ist eine coole Idee!
Plattenplatz habe ich dafür nicht mehr aber ich habe noch zwei Slots für neue HDD frei. Die werde ich dann bei Bedarf einfach nach kaufen.
Es müssen auch nicht täglich 1,5 TB kopiert werden. Das ist die Gesamtgröße der Daten. Die müssen also nur beim ersten rsync-Durchlauf rüber geschoben werden.
Ab dem zweiten rsync-Durchlauf schätze ich, dass "nur" Änderungen in der Größenordnung von 1-5 GB syncronisiert werden müssen.
Da rsync in meinem ersten (gescheiterten) Versuch bereits 500 GB in 24 Stunden geschafft hat, hoffe ich, dass es passen wird.

[hobbyadmin]

Jetzt bin ich mal gespannt.
Ich habe jetzt eine externe HDD über USB 3.0 an das NAS angeschlossen.
Nur der erste Sync-Vorgang erfolgt jetzt mit rsync auf die externe HDD. Diese Daten werden danach nicht mehr verändert.
Wenn das fertig ist, werde ich den zweiten Durchlauf von der externen HDD auf den entfernten Server durchführen.
Wenn das auch funktioniert hat, werde ich den Sync-Vorgang wieder (direkt) von NAS auf den entfernten Server laufen lassen.

Ich hoffe, dass durch diese Vorgehensweise, rsync den ersten Sync auf den entfernten Server ohne Probleme durchführen kann. Die Daten auf der externen HDD bleiben ja gleich.

Vielen Dank für die Hilfe.
Ich werde berichten....

[hobbyadmin]

Ich habe mich nochmal umentschieden.
Ich werde zunächst rsync auf eine verschlüsselte externe HDD durchführen. Die Verschlüsselung führe ich am QNAP-NAS durch, damit es keine Probleme damit gibt.
Danach werde ich jedoch die externe HDD an den Backup-Server anschließen und alle weiteren rsync-Durchläufe auf diese externe HDD schreiben lassen.
Im Falle eines Daten-GAU kann ich die externe HDD dann sehr schnell abziehen und am Arbeitsplatz einspielen.
Das zurück kopieren über das Internet dauert mir zu lange.

[hobbyadmin]

So Leute,

es ist geschafft. Und es hat länger gedauert als ich erwartet habe!
Der erste rsync-Durchlauf von NAS auf externe USB 3.0 HDD hat fast 10 Stunden gedauert. Die externe HDD war dabei direkt am NAS angeschlossen.
Die externe HDD ist nun am Backup-Server eingehängt und die Rechte musste ich nochmals anpassen. Hatte ich mal wieder vergessen.
Rsync über SSH vom QNAP-NAS auf den Backup-Server funktioniert jetzt einwandfrei. Rsync benötigt ca. 20-30 Minuten, um die Dateien abzugleichen und nur die Veränderungen zu kopieren.
Genau so habe ich mir das gedacht.
Den Befehl trage ich jetzt in crontab ein und dann habe ich endlich ein funktionierendes und einigermaßen sicheres Backup auf einen externen Backup-Server.

[KP97]

Glückwunsch!
Es zahlt sich doch aus wenn man durchhält...

[hobbyadmin]

Vielen Dank!
rsync läuft jetzt und ich habe noch ne Frage zur Log-Datei. Die ist meiner Meinung nach sehr übersichtlich. Es werden noch nichtmals die Angaben von --stats gespeichert. Kann ich die Ausgabe der Log-Datei durch einen Befehl etwas ausführlicher gestalten?

Das ist mein rsync-Befehl:

Code: Alles auswählen

rsync -avzSAXHP -e "ssh -p PORT" --exclude=@Recycle --delete --stats --log-file=/share/homes/admin/rsync_arbeit.log /share/Public/ arbeit@ip.adresse.de:/mnt/arbeit

Und das ist die Ausgabe der Log-Datei:

2021/07/11 03:15:02 [27542] building file list
2021/07/11 03:16:10 [27542] *deleting Backup Job 1/Backup Job 1D2021-06-26T220325_2828.vbk
2021/07/11 03:16:10 [27542] .d..t...... Backup Job 1/
2021/07/11 03:16:10 [27542] <f..t.....x Backup Job 1/Backup Job 1.vbm

Etwas dünn, oder?

[hobbyadmin]

Oh man, das wird eine unendliche Geschichte!
Ich habe mit "ps" geprüft, ob rsync noch läuft. Und siehe da, der Prozess lief noch.
Der Upload über rsync läuft sehr langsam. es sind nur 1,15 MB/s.
Der Router meldet aktuell eine mögliche Uploadgeschwindigkeit von 34.2 MB/s.
Der Router am Ziel meldet eine Downloadgeschwindigkeit von 114.2 MB/s.

Mit 1.15 MB/s schafft rsync es in 24 Stunden nicht, die Änderungen zu kopieren. Der Prozess soll laut rsync 34 Stunden dauern.
Was ist da los?

Ist das eine falsche Einstellung bei mir irgendwo oder sind die Backups von der VM einfach zu groß?

[Tintom]

Ist das eine falsche Einstellung bei mir irgendwo oder sind die Backups von der VM einfach zu groß?

Mir fallen zwei Dinge auf:

• Grob überschlagen sind das >100GB, die da jeden Tag übertragen werden sollen. Wird tatsächlich diese Menge jeden Tag geändert oder ist da noch Overhead mit drin?
• Du verwendest bei rsync die Option -z. Die Host-CPU (hier: die CPU vom NAS) übernimmt dann das Komprimieren der Daten. Die CPUs in 'nem NAS sind nicht für ihre Schnelligkeit bekannt und daher bremst die Option dein Backup gehörig aus. Gerade wenn du so eine "dicke Leitung" hast würde ich ganz auf Komprimierung verzichten.

[slu]

• Grob überschlagen sind das >100GB, die da jeden Tag übertragen werden sollen. Wird tatsächlich diese Menge jeden Tag geändert oder ist da noch Overhead mit drin?
• Du verwendest bei rsync die Option -z. Die Host-CPU (hier: die CPU vom NAS) übernimmt dann das Komprimieren der Daten. Die CPUs in 'nem NAS sind nicht für ihre Schnelligkeit bekannt und daher bremst die Option dein Backup gehörig aus. Gerade wenn du so eine "dicke Leitung" hast würde ich ganz auf Komprimierung verzichten.

Evtl. ist das auch noch für dich interessant:
viewtopic.php?f=30&t=181353

[hobbyadmin]

Ja, die Dateigröße ist leider korrekt. Scheinbar wird vom Server (der VM) jede Woche ein Vollbackup gemacht. Das passiert wohl samstags oder sonntags. Von Montag bis Freitag werden dann scheinbar nur die Veränderungen gesichert.
So ganz verstehe ich das Konzept noch nicht. Das Programm, dass die Backups von der VM auf der Windows Maschine macht heißt "Veem" oder "Veam". Davon habe ich keine Ahnung und lasse die Finger da weg : )

Das Netzwerk am Zielrechner ist nicht das Problem. Dort habe ich zur Probe ein rsync mit den exakt gleichen Einstellungen laufen lassen, natürlich auch über das Internet und dort habe ich Datenraten von 80-192 MB/s erhalten.
Ich werde also bei der Quelle (QNAP-NAS) auf die Suche gehen. Vielleicht sind die Netzwerkeinstellungen ja auch irgendwo falsch eingestellt oder die Firewall bremst das Ganze aus. Mal sehen.

Den Schalter "z" werde ich raus nehmen, danke für den Hinweis. Das hat bei meinen Test im Ziel-Netzwerk auch keine Vorteil gebracht. Zusätzlich werde ich morgen mal die CPU-Auslastung auf dem QNAP-NAS kontrollieren. Im Moment hat es nichts zu tun und die CPU steht bei 2%. Vielleicht ist rsync mit ssh einfach zu viel für das sch*** Ding. Das wäre echt traurig!

[hobbyadmin]

Es funktioniert nicht. Die Datenraten sind und bleiben zu gering. Ich vermute, dass in den Einstellungen des QNAP oder der Firewall etwas nicht stimmt. Werde da nochmal suchen.
Ich kann aber keinem raten, so ein NAS im Terminal zu nutzen. Das NAS selbst ist nämlich so eine Art Super-root. Alles, was ich als root im Terminal ändere, ist nach einem Neustart des Gerätes wieder gelöscht. Der Ober-Hammer, oder?
Ich traue dem Ding nicht mehr...

[heisenberg]

Alles, was ich als root im Terminal ändere, ist nach einem Neustart des Gerätes wieder gelöscht. Der Ober-Hammer, oder?

Das ist aus technischer Sicht schon verständlich. So ein NAS ist ja ein System, dass für das Betriebssystem statt einer Festplatte wahrscheinlich einen Flash-Speicher hat. Und da kann man nicht so einfach drauf rumschreiben, wie auf der Platte. Der Unterschied zwischen den beiden Technologien ist der, dass die Flashspeicher nur eine begrenzte Anzahl von Schreibvorgängen erlaubt, bevor der Speicher unbrauchbar wird. Deswegen wird hier üblicherweise beim Starten ein Image gelesen und das Dateisystem liegt dann im RAM. Entsprechend sind die meisten Einstellungen beim Reboot dann weg. Das ist hier wohl eher ein Merkmal der Embedded-Umgebung.

Da aber - ich vermute mal fast alle - Systeme irgendwie dann doch wieder auf irgendwelchen OSS Projekten basieren, teilweise wahrscheinlich auch schon sehr alter Generation, gibt's da bestimmt auch immer eine Möglichkeit, Einstellungen dauerhaft(=persistent) zu speichern. Es ist halt nicht so simpel wie auf Desktopsystemen: Config liegt in /etc und fertig.

Auch bei aktuellen OSS Projekten(OpenWRT) z. B. sind manche Einstellungen nicht automatisch persistent. Da muss man z. B. spezielle Befehle verwenden um diese in den Flash-Speicher zu schreiben. (z. B. nvram set).

[hobbyadmin]

Sch**** es geht!!!

Moin!
Ich habe nun doch nochmal einen Raspi4 mit 8 GB RAM in das Netzwerk gehängt.
Der Raspi4 holt zunächst ein Backup vom QNAP-NAS und sendet danach ein Backup über das Internet zum Backup-Server.
Das Ganze wieder mit Rsync und SSH. Auch die Rsync-Optionen sind gleich geblieben.
Und das geht jetzt wie die Feuerwehr!
Im lokalen Netzwerk dauert das nächtliche Backup ca. 7 Minuten.
Das zweite Backup über das Internet braucht ca. 40-45 Minuten.
Ich bin glücklich.
So bleibt das erst einmal.

Wenn ich wieder Kraft geschöpft habe, möchte ich gerne rsnapshot für das Backup auf dem raspi4 einsetzen.
Wenn es soweit ist, werde ich mich wahrscheinlich wieder bei Euch melden : )

Mein Fazit:
Verwendet niemals ein NAS im Terminal. Es sieht zunächst aus wie ein normales Linux. Es ist aber tatsächlich ein irgendwie verändertes Linux. Man läuft dauernd vor Wände oder es funktioniert gar nicht.
Diese Dinger sind scheinbar nur für die (ebenfalls eingeschränkte) Benutzung über die mitgelieferte GUI gemacht.

Lieben Dank für alles!

[hobbyadmin]

Ich muss leider doch nochmal ein Update liefern.

Nachdem mein Backup mit Rsync stabil gelaufen ist, hat der Server scheinbar irgendwann ein so großes Backup gemacht, dass rsync das wieder nicht in 24 Stunden syncronisieren konnte. Nach 24 Stunden kam dann die Zwangstrennung des DSL-Anbieters und Rsync begann wieder von vorne. So ein Mist....

Aber - ich habe mich im Netz umgesehen und bin auch fündig geworden. : )
Ich habe jetzt "Borg Backup" installiert und damit scheint es zu funktionieren. Die Software ist schneller und sie speichert die Backups sehr platzsparend. Das Wichtigste ist aber, dass sich die Software merkt, was schon übertragen wurde. Nach der Zwangstrennung durch den DSL-Anbieter macht Borg also genau da weiter, wo es unterbrochen wurde. Das funktioniert auch mit großen VM Dateien.
Ich beobachte das weiter. Aber im Moment sieht es sehr gut aus.

Wenn also jemand große Datenmengen zu sichern hat, sollte er mal Borg Backup ausprobieren...

[hobbyadmin]

So Leute,

jetzt mal Butter bei die Fische! : )
Ich habe jetzt Borg Backup laufen lassen. Das Programm hat ca. 8 Tage gebraucht, bis es fertig war.
Die Quelle hatte eine Größe von 1.42 TB. Borg Backup hat diese Daten komprimiert und dedubliziert, sodass die Dateigröße am Ziel nur noch 571.75 GB beträgt. Ich bin schwer beeindruckt.
Das Programm zerhackt scheinbar auch die großen VM-Dateien in kleine Stücke und überträgt nur veränderte Dateien die innerhalb der VM entstanden sind.
Der erste Backup-Durchlauf wurde ebenfalls jede NAcht von der Zwangstrennung des DSL-Anbieters unterbrochen. Ich musste Borg Backup dann meist manuell neu starten. Borg hat dann aber genau dort weiter gemacht, wo es unterbrochen wurde.

Bisher kann ich das Programm empfehlen. Wenn Ihr auch Backups machen müsst, bei denen die 24 Stunden eines Tages nicht ausreichen, dann ist Borg Backup durchaus einen Test wert!

[letzter3]

Schon mal ne Wiederherstellung getestet?

[hobbyadmin]

Nein, eine Wiederherstellung habe ich noch nicht getestet. Das Ganze ist ja noch sehr neu.
Wenn ich die Zeit habe, werde ich am WE mal eine Wiederherstellung versuchen.

[hobbyadmin]

Da bin ich wieder,

Borg Backup läuft weiter sehr stabil.
Das erste Backup hat 8 Tage gedauert, das zweite Backup hat etwas über einen Tag gebraucht und seit dem dritten Backup braucht der Durchlauf nur noch zwei bis sieben Stunden. Damit kann ich gut leben. Das Backup wird jetzt täglich ausgeführt.

Eine Wiederherstellung habe ich noch nicht probiert. Das Backupverzeichnis läßt sich aber über FUSE einbinden und dann kann man die Ordnerstruktur sehen, dort hinein wechseln und offensichtlich sogar einzelne Dateien wiederherstellen. Zum Testen habe ich mal eine Datei und einen Ordner dort heraus kopiert und das funktionierte problemlos.
Wenn man jedoch das gesamte Backup wiederherstellen möchte, wird das wahrscheinlich auch funktionieren. Es würde aber bestimmt wieder krötenlangsam sein, weil bei mir hier die Internetverbindung der Flaschenhals ist.
Genau aus diesem Grund habe ich auf dem Zielrechner eine verschlüsselte externe HDD genommen. Im Falle eines Daten-GAUs würde ich die externe HDD dann direkt an den Quellrechner anstecken und von dort aus die Wiederherstellung starten. Das wird aber dann immer noch mehrere Stunden dauern. Denn zu meiner eigenen Überraschung brauchen 1.5 TB selbst über USB3 seeeehr lange.

[hobbyadmin]

Moin!
Das Backup über Borg-Backup hat sich jetzt endgültig zurecht geruckelt und läuft jede Nacht problemlos durch.
In der Woche braucht das Backup ca. 20-40 Minuten.
Am Wochenende braucht es ca. 4 Stunden.
Das ist in Ordnung für mich. Das bleibt erstmal so.

Borg-Backup ist also eine funktionierende Alternative, wenn die Internetverbindung zu langsam oder die täglichen Datenmengen zu groß sind.