Wiederholtes Backup von 2.2 TB mit Backup Client sehr lange

[taubers]

Hallo zusammen.

Ich benutze Backup Client, um 2.2TB HDD von Linux host auf PBS zu sichern.

Der erste Backup hat 20h gebraucht. Das wäre auch ok.

Jetzt läuft der zweite Backup und ich habe erwartet, dass es mindestens 10 Mal schneller passieren wird, aber nach 4.5 Stunden läuft es immer noch. Meine Vermutung war, dass es mit dem schon eingebauten incremental backup feature am zweiten Mal viel schneller gehen sollte.

Mache ich was falsch oder ist es normal so? Vielleicht ist dann für so große Backups nur sowas wie rsync geeignet?

Kann man auch irgendwie auch den Progress sehen, wenn man mit Backup Client arbeitet?

 

[Dunuin]

Sollte wegen inkrementellen Backups schon schneller gehen. Aber nicht vergessen das auch jedes inkrementelle Backup erstmal alle 2.2TB Stück für Stück öffnen, hashen und dann mit den Hashes vom PBS vergleichen muss. Wirklich gesendet wird da vielleicht garnicht viel, aber immer die kompletten 2.2TB zu hashen braucht halt auch seine Zeit. Gerade wenn auf der HDD viele kleine Dateien liegen mit denen HDDs ja eh nicht so gut umgehen können wegen mangelnder IOPS.

 

[taubers]

Danke, @Dunuin!

Ja, es sind viele kleine Dateinen. Ich wundere mich, ob dieser Vergleichsprozess nicht auf Dauer meine HDD überlastet. Meinst Du es ginge mit rsync oder rdiff (was Du mir einmal schon gut vorgeschlagen hast) schneller solche Backups zu machen?

 

[Dunuin]

Hängt davon ab wie sicher du rsync die Dateien vergleichen lässt. PBS muss zwangsweise alles hashen weil ja noch dedupliziert wird und man sich keinen Datenverlust leisten kann. Wenn du Rsync ebenfalls alles hashen lassen würdest, dann wäre Rsync vermutlich auch nicht viel schneller.
Schneller wäre es natürlich, wenn du Rsync nur Dateien anhand von Namen/Größe/Änderungsdatum vergleichen lässt. Dann muss Rsync ja nur oberflächlich die Metadaten vergleichen und nicht jede Datei einmal komplett einlesen. Ist dann natürlich aber auch fehleranfälliger.

 

[taubers]

na, ja, auf Fehler wollen verzichten. Und bei solchen Datenmenge meinst Du normale ZFS snapshots (zfs send -i -r Pool/Dataset@LetzterSnapshot| zfs receive Pool/Dataset) könnten eine schnelle und sichere Lösung sein?

 

[Dunuin]

Ja, ZFS Replikation klappt wunderbar. Ich schicke hier per Script einmal die Woche 32TB an HDDs vom einen Server zum anderen Server rüber. Wenn sich da nicht viel an neuen Daten angesammelt hat ist das innerhalb weniger Minuten durch. Da ist dann nur die Snapshot Retention etwas nervig. Ich will ja auch einen gewissen Schutz gegen Ransomware haben, also muss ich alle Snapshots für mindestens einige Monate behalten. Dann dauert es aber auch entsprechend mindestens einige Monate, bis dann etwas von mir gelöschtes auch wirklich gelöscht ist. Lösche ich da z.B. jede Woche 200GB und habe eine Retention von 3 Monaten, dann verschwenden die Snapshots 2,4 TB an Platz.
Aber wenn auf beiden Rechnern eh ZFS läuft, dann ist eine Replikation schon so ziemlich das schnellste was du machen kannst.

 

[taubers]

ZFS scheint für mich ein Weltwunder zu sein da es so viele Dinge so effizient macht. Danke Dir für die Ermutigung die großen Backups mit ZFS zu machen!

 

[Dunuin]

Gibt da übrigens auch massig Scripts auf Github und Co, welche die Replikation erleichtern. Deutlich schneller wird die Replikation z.B. wenn man statt nur SSH zusätzlich noch netcat nutzt, sofern man nicht lokal replizieren kann.

 

[taubers]

cool! Über netcat habe ich noch nicht gehört! Muss mal probieren

 

[Beatle]

Hallo,

ich hatte die Probleme auch. Bei mir gab es zwei Ursachen:
1. Schlechte USB Festplatte. Ich habe mehrer Toshiba Canvio Basics 4TB. Diese werden beim längeren Schreiben von großen Datenmengen urplötzlich langsam. Ich habe das Problem mit allen Toshiba Canvio Basics 4TB Platten. Die 2TB Platten der selben Serie funktionieren dagegen einwandfrei.
2. Die zu sichernde VM ist ein vlollverschlüsseltes Debian System. Nachdem ich die VM auf ein Unverschlüsseltes System neu aufgesetzt habe, wurde das inkrementelle Backaup wesentlich schneller.

 

[Dunuin]

Diese werden beim längeren Schreiben von großen Datenmengen urplötzlich langsam. Ich habe das Problem mit allen Toshiba Canvio Basics 4TB Platten. Die 2TB Platten der selben Serie funktionieren dagegen einwandfrei.

Das klingt nach SMR HDDs. HDDs die SMR statt CMR nutzen sollte man nie kaufen. Die wirken nur so als wenn sie normal schnell wären (weil erst alles in den RAM/CMR-Cache geschrieben wird) und sobald der Cache voll ist muss alles in den echten SMR-Bereich der HDD geschrieben werden und dann bricht die Schreibrate ins Bodenlose ein.
Da gab es ja 2020 erst einen Shitstorm zu wegen WD Red HDDs die heimlich von CMR auf SMR umgestellt wurden: https://www.computerbase.de/2021-06...ei-vergleich-4-bis-7-dollar-pro-hdd-erhalten/

 

[Beatle]

Das klingt nach SMR HDDs. HDDs die SMR statt CMR nutzen sollte man nie kaufen. Die wirken nur so als wenn sie normal schnell wären (weil erst alles in den RAM/CMR-Cache geschrieben wird) und sobald der Cache voll ist muss alles in den echten SMR-Bereich der HDD geschrieben werden und dann bricht die Schreibrate ins Bodenlose ein.
Da gab es ja 2020 erst einen Shitstorm zu wegen WD Red HDDs die heimlich von CMR auf SMR umgestellt wurden: https://www.computerbase.de/2021-06...ei-vergleich-4-bis-7-dollar-pro-hdd-erhalten/

Danke für die Info.
Da werde ich das nächste mal drauf achten...

 

[taubers]

Hallo,

ich hatte die Probleme auch. Bei mir gab es zwei Ursachen:
1. Schlechte USB Festplatte. Ich habe mehrer Toshiba Canvio Basics 4TB. Diese werden beim längeren Schreiben von großen Datenmengen urplötzlich langsam. Ich habe das Problem mit allen Toshiba Canvio Basics 4TB Platten. Die 2TB Platten der selben Serie funktionieren dagegen einwandfrei.
2. Die zu sichernde VM ist ein vlollverschlüsseltes Debian System. Nachdem ich die VM auf ein Unverschlüsseltes System neu aufgesetzt habe, wurde das inkrementelle Backaup wesentlich schneller.

Ich hatte die WDC WUH721818ALE6L4 benutzt.