cobo
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
Neue externe Festplatte gekauft für Backups: Seagate "One Touch", 5TB. Angeschlossen via USB3 an Thinkpad 590 mit Ubuntu. Auch früher schon habe ich mit anderen Festplatten und "Back in Time" Backups gemacht, also grundsätzlich bin ich damit klar gekommen. Dass solche Backups tendenziell einige Stunden dauern bin ich darum schon gewohnt. Als erstes habe ich gemerkt, dass rsync (welches im Hintergrund das Arbeitspferd ist) scheinbar keine Links setzen kann. Der Grund war offensichtlich, dass das neue Teil mit extFAT formatiert war. Kurzerhand mit gnome-disks neu partitioniert: Die bestehende kleine "Hilfspartition" für ein Windows-Backuptool sowie die Hauptpartition (extFAT) gelöscht und für die ganze Platte eine Partition mit NTFS gelegt. Ich war etwas erstaunt, dass ich nach dieser Partitionierung gleich auf die Platte schreiben konnte: Ich hatte erwartet, dass man nach dem "partitionieren" auch noch erst "formatieren" muss. Vielleicht war das nur früher so!? Dann mit "Back in Time" losgelegt, und die Fehler wegen Links waren weg. Zu Beginn sah es wunderbar aus: rund 60MB/sek (in Back In Time). Nach ein paar Stunden waren es dann aber nur noch rund 2MB/sek, nachdem erst unter 80GB von rund 300GB geschrieben waren. Ok, ist das die "Erstsicherung", und für die muss ich halt man 1-2 Tage rechnen!? Recherchen von wegen möglichen Mount-Parameter-Problemen oder rsync-Optionen haben mir keine Anhaltspunkte zur Verbesserung gegeben, also sei's drum. Heute aber, nach einer Nacht durchgelaufen, war die Geschwindigkeit schon nur noch bei ein paar kb pro Sekunde und die 80GB waren noch immer nicht erreicht: Da habe ich abgebrochen, weil ich jetzt gemäss Hochrechnung JAHRE bräuchte für die Sicherung! Ok, ich habe die Partitionierung/Formatierung nochmals auf einem Windows-Rechner neu gemacht, einfach mal falls da mit Linux was falsch gelaufen wäre. Und einen Benchmark mit gnome-disks durchgeführt, was die Platte technisch zum lesen/schreiben so hergeben würde: leider nicht sehr "berauschend": ca. 26MB/s für lesen, ca. 0.5MB/s für schreiben, mit 1MB-Samples. Da waren die obigen höheren Geschwindigkeiten wohl irgend ein Durchsatz, der sich inkl. irgendwelche Verarbeitungsschritte ergibt und nicht die reine Schreibgeschwindigkeit. Würde ich nun einen Durchschnitt 0.5MB/s nehmen, dann bräuchte ich für mein erstes Backup der 300GB als reine Schreibzeit gerechnet rund eine Woche (7 Tage)! Frage: Habe ich da ganz einfach einen Fehlkauf getätigt oder lässt sich da was aufbessern??
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1069
|
Es gab mal einen Backintime-Bug mit niedriger Schteibrate bei alten Backups auf die aufgebaut wurde. Aber dein Backup ist ja neu angelegt mit aktueller Software. Da der Benchmark derart schlechte Werte liefert würde ich hier auf die Hardware tippen. Um welche Platte geht es denn? Hast du die Möglichkeit eine andere Platte an dem PC zu testen? Und die Möglichkeit diese Platte an einem anderen Rechner zu benchmarken?
|
cobo
(Themenstarter)
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
Wie gesagt: Seagate "One Touch", 5TB HDD https://www.seagate.com/de/de/products/external-hard-drives/one-touch-external-drives/ Eine Review dieses Laufwerks ist z.B. hier zu finden: https://www.techradar.com/reviews/seagate-backup-plus-portable-5tb-hard-drive Mir scheint jedenfalls dass es genau das ist, mit irgendeinem Softwarebundle für Windows dabei, welches ich aber schon platt gemacht habe 😉 Was dort über die "Performance" geschrieben steht ist allerdings weit entfernt von dem was ich gefunden habe:
"Overall, the drive performed above average in our two tests (CrystalDiskMark 6.0.2 and Atto 4) achieving read speeds of between 131 and 146MBps, and write speeds of between 130 and 139MBps. A 10GB file was transferred in about 78 seconds from the laptop’s drive to the portable device, which equates to a real-life speed of around 128MBps – half the speed of some of the slower external solid-state drives we’ve evaluated."
Über 100 MB pro Sekunde sind jedenfalls Lichtjahre entfernt von dem was ich jetzt hier gemessen habe! Allerdings habe ich auch extra meinen Benchmark laufen lassen mit "kleinen" Files von je 1MB, weil ich dachte, dass mein Backup ja aus vielen kleinen Files besteht. Vielleicht ist diese Überlegung aber auch falsch: Vielleicht schreibt der Benchmark diese vielen kleinen Files absichtlich verstreut über die ganze Platte, während ein Backup auch viele kleine Files sequentiell eins hinter das andere schreibt, sodass die Zeit für's Positionieren dann praktisch weg fallen würde. Ein wenig habe ich Angst, dass ich durch das Neupartitionieren und Formatieren vielleicht etwas "vermurkst" haben könnte, aber dann frage ich mich doch auch, warum extFAT so ungeheuer viel schneller sein soll als NTFS? Kommt mir auch wiederum sehr komisch vor! Ich habe kleinere, ältere Festplatten, auf die ich früher Backups gemacht habe und die lange nicht so lahm waren: Muss ich vergleichsmässig jetzt auch nochmal benchmarken. Und ich habe einen Rechner vom genau gleichen Typ, aber mit Windows drauf: Da muss ich mir vielleicht irgendein Windows-Benchmarktool suchen und es dort einmal probieren. Allerdings hatte ich auch früher nicht den Eindruck, dass die Kombination "Back-In-Time" (mit rsync "im Hintergrund") eine echte Rakete ist: ein paar Stunden habe ich für ein inkrementelles Backup immer gerechnet. Wobei das Teil ja mit "hard links" arbeitet: Jedes Backup sieht aus wie ein komplettes Backup, aber Dateien, die für Dateien, die sich nicht geändert haben, verweist der Directory-Eintrag einfach auf die alte Kopie. Das ist vielleicht ein Prozess, der auch eine Menge Zeit kostet für viele Dateien(!?)
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 1089
|
Moin, NTFS für eine Linux-Datensicherung !? Mutig, sehr sehr mutig... Zur Datensicherung lies auch mal hier nach: https://wiki.ubuntuusers.de/Skripte/Backupscript/ Das Skript funktioniert wenigstens, und tägliches Backup ist eine Sache von wenigen Minuten (ausser beim ersten Mal, natürlich, und vor allem, wenn du ein richtiges Dateisystem verwendest). Viele freundliche Grüsse, juribel
|
Bleys
Anmeldungsdatum: 13. August 2006
Beiträge: 6172
|
Ich haue mal in die gleiche Kerbe wie juribel NTFS in Verbindung mit BiT ist eine ganz schlechte Idee! Damit funktioniert z.B. keine inkrementelle Datensicherung. Es wird immer alles gesichert.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Bleys schrieb: NTFS in Verbindung mit BiT ist eine ganz schlechte Idee! Damit funktioniert z.B. keine inkrementelle Datensicherung. Es wird immer alles gesichert.
Ist jetzt OT, aber: Warum? Persönlich würde ich auch nicht auf NTFS setzen, aber ob die inkrementelle Sicherung funktioniert oder nicht sollte doch unabhängig vom Dateisystem sein, nicht? Oder fordert Back in Time hier tatsächlich ein Dateisystem wie bspw. BTRFS mit CoW?
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 1089
|
Moin, ich hab mal irgendwo gelesen, dass NTFS mittlerweile auch Hard links unterstützen soll, aber ob die auch unter Linux so funktionieren bzw. ob sie überhaupt richtig funktionieren, das bezweifele ich doch sehr. Wie gesagt, unter einem Linux-Dateisystem (ich benutze ext4) ist die Datensicherung eine Sache weniger Minuten, und ich hab VIELE Daten (über 420 GBytes), die ich beinahe täglich sichere. Auf meiner 2 TBytes externen Sicherungsplatte befinden sich jetzt ca. 170 inkrementelle Sicherungen, und diese belegen nur ungefähr 1 TByte, obwohl jede dieser Sicherungen dank Hard links für sich vollständig ist. Es kommt wirklich darauf an, dass Hard links gut unterstützt werden (wie bei ext4), denn sonst wird mit jeder Datensicherung alles kopiert, und das kann wirklich Stunden dauern und kostet ntaürlich entsprechend viel Plattenplatz. Viele freundliche Grüsse, juribel
|
Bleys
Anmeldungsdatum: 13. August 2006
Beiträge: 6172
|
Developer92 schrieb: Bleys schrieb: NTFS in Verbindung mit BiT ist eine ganz schlechte Idee! Damit funktioniert z.B. keine inkrementelle Datensicherung. Es wird immer alles gesichert.
Ist jetzt OT, aber: Warum? Persönlich würde ich auch nicht auf NTFS setzen, aber ob die inkrementelle Sicherung funktioniert oder nicht sollte doch unabhängig vom Dateisystem sein, nicht? Oder fordert Back in Time hier tatsächlich ein Dateisystem wie bspw. BTRFS mit CoW?
Grundsätzlich sollte NTFS mit BiT funktionieren, wird aber von BiT selbst nicht empfohlen. Sollte... Meine eigenen Erfahrungen und die Google Ergebnisliste für "BackInTime ntfs" sagen da etwas anderes. Bei mir war z.B. auch kein inkrementelle Backup möglich. Es wurde immer ein komplettes Backup durchgeführt. Dann können durch BiT längere Pfade erzeugt werden als Windows zulässt. Die NTFS Backup HDD mal "aus Versehen" unter Windows defragmentieren und Du hast Daten Verlust. Also warum sollte man NTFS nehmen? FAQ BiT
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 1089
|
@Developer92: Dumme Frage vielleicht, aber was ist CoW? Viele freundliche Grüsse, juribel
|
cobo
(Themenstarter)
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
juribel schrieb: @Developer92: Dumme Frage vielleicht, aber was ist CoW? Viele freundliche Grüsse, juribel
Das liess sich leicht herausfinden: https://wiki.archlinux.org/title/Btrfs CoW heisst offenbar "Copy on Write": Copy-on-Write (CoW)
By default, Btrfs uses copy-on-write for all files all the time. Writes do not overwrite data in place; instead, a modified copy of the block is written to a new location, and metadata is updated to point at the new location. See the Btrfs Sysadmin Guide section for implementation details, as well as advantages and disadvantages.
|
cobo
(Themenstarter)
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
Danke für all eure Hinweise, die mehr oder weniger darauf hinaus laufen, lieber ext4 oder btrfs zu verwenden anstatt NTFS! Ich glaube, dass ich genau das jetzt mal versuchen will, da die andere Lösung wirklich einfach indiskutabel ist. Vielleicht noch ein Detail dazu: Ich hatte die NTFS-Partition offenbar inklusive einer Art Quick-Formatierung (die keine spürbare Zeit benötigte) unter Ubuntu gemacht, und dann, nach diesen schrecklichen Resultaten, nochmals unter Windows wiederholt. Interessanterweise hat ein Festplatten-Performance-Benchmark mit gnome-disks durchaus einen Unterschied gezeigt, aber nicht beim schreiben, sondern nur beim lesen: die Windows-formatierte Platte konnte mindestens doppelt so schnell lesen. Ausserdem geschah die Formatierung auf dem Windows-System auch nicht quasi "augenblicklich", sondern dauerte, trotz "quick format", durchaus ein zwei Minuten. Warum habe ich überhaupt NTFS benutzt? Nun ganz einfach: Weil ich damit die Freiheit habe, das Backup auch mit einem Windows-Rechner zu lesen! Und die BiT-Backups haben ja die Eigenschaft, im Gegensatz zu anderen, die ich auf anderen Systemen von früher kannte, dass man das Zurückschreiben notfalls einfach mit normalem Dateitransfer machen kann, also auch einzelne Dateien heraus picken usw., notfalls dann eben auch von einem Windows-System aus. (Ok, früher von mir benutzte Backup-Systeme haben mit Bändern funktioniert - das waren noch Zeiten... 😉 ) Mein Hardware-Setup hier in meiner Einmann-Firma mit eigener Software-Entwicklung ist halt das folgende: Zwei identische Thinkpad-Notebooks (T590), einmal unter Ubuntu mit einer 1TB-Platte und einmal unter Windows 10 mit einer 500GB-Platte. Die grosse Platte unter Linux enthält einen Ordner "Main", der wiederum über das LAN auf den Windows-Rechner als "Laufwerk M:" "gemappt" ist. Dorthin wird alles gespeichert was ein Backup braucht, denn ich will nicht zwei Rechner "backuppen" müssen! Klar mache ich dann nicht vom Windows-Rechner aus über's LAN grösser "Builds", aber ich schiebe z.B. allen Windows-Sourcecode via git auf's "Laufwerk M:", dh. auf den Linux-Rechner, der sowieso mein "Arbeitspferd" ist: Windows brauche ich halt weil die Kunden das auch haben. Und die 1TB-Platte ist natürlich nicht mit NTFS, sondern mit ext4 formatiert. Die Datenmenge, die in diesem "Main"-Folder steht und für die ich das Backup regelmässig mache, ist zur Zeit etwa 300GB. Bisher hatte ich eine 500GB-Platte dafür in Gebrauch - und ich habe gestaunt, wie lange die das mit gemacht hat! Sie ist tatsächlich mit NTFS formatiert, und ich habe auch schon mit BiT gearbeitet. Richtig "flott" war das nie, aber das Ding rödelt dann halt so im Hintergrund herum und macht sein Backup, oder auch über Nacht. Muss nicht zwingend täglich laufen, da ich zugleich auch noch eine Spiegelung auf meinen Cloud-Speicher mache, die ständig fast aktuell sein sollte. Plus die Sicherung des Sourcecodes auf gitlab. Mit Sicherheit hat BiT für die inkrementellen Backups nicht jedes Mal alles komplett neu geschrieben! Denn ich habe auf dieser jetzt eben komplett vollen Platte immerhin 11 Backups, und in jedem Backup-Folder erscheinen die Dateien komplett, was ja offensichtlich nur mit Hard-Links (oder mit Zauberei...) erreicht werden kann. Scheint also durchaus zu gehen! Aus euren Ausführungen und meinen obigen Erfahrungen schliesse ich nun aber, dass es halt vielleicht ein Unterschied ist, ob ich das mit einer "kleineren" 500GB-Platte mache oder mit einer 5TB-Platte: Vielleicht wird da einfach eine Grenze für NTFS überschritten wo es nicht mehr mitmacht? In meinem Setup hat NTFS natürlich den Vorteil, dass ich im falle eines "Abkratzens" meines Linux-Rechners inkl. "Main"-Folder dann wenigstens das Backup auch noch unter Windows lesen könnte. Da ich aber nicht vor habe, in absehbarer Zukunft ganz auf Linux zu verzichten, ist das aber mehr eine Komfortlösung als zwingend notwendig. Und wenn das, was mit NTFS so miserabel läuft, mit ext4 dann einfach funktioniert, dann ist das doch auch ein genügender Grund, die Sache mal so zu probieren! Ich werde es dann mal tun und mich wieder melden, um Erfolg oder Misserfolg mit eventuell Interessierten zu teilen.
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 1089
|
Viel Erfolg! Rechne doch Interesse halber einfach mal nach. Wie gross ist dein Datenbestand, den du sicherst? Wie gross ist deine volle Sicherungsplatte? 11 Sicherungen sind ja wirklich nicht viel, siehe mein früheres Posting. Viele freundliche Grüsse, juribel
|
cobo
(Themenstarter)
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
Die alte Platte mit NTFS hat 500 GB und enthält neben den 11 Backups vom aktuellen Setup auch noch viele Backups meines früheren "OpenSuxe"-Systems. Ich habe sie jetzt mal an den Windows-Rechner angeschlossen und "TreeSize" gefragt, um mir zu erzählen, wie viele Daten er da drauf jetzt "sieht"! Das scheint den jetzt erst mal zu beschäftigen - keine Ahnung wie lange! Ist mir im Moment auch egal, da ich am Linux-Rechner arbeite. Wenn der am Schluss mehr als 500 GB findet dürfte der Fall klar sein: NTFS hätte dann tatsächlich Hard Links benutzt. Unterdessen arbeitet gnome-disks an der Erstellung der 5TB-Partition mit ext4: Das scheint deutlich länger zu dauern als die Erstellung der NTFS-Partition und ist beim ersten Versuch sogar misslungen... Aber ich bleibe dran!
|
san04
Anmeldungsdatum: 19. Januar 2010
Beiträge: 1069
|
cobo schrieb:
Unterdessen arbeitet gnome-disks an der Erstellung der 5TB-Partition mit ext4: Das scheint deutlich länger zu dauern als die Erstellung der NTFS-Partition und ist beim ersten Versuch sogar misslungen... Aber ich bleibe dran!
Das sollte nicht lange dauern... Das Partitionierungsschemata ist aber GPT? MBR funktioniert nur bis 2 TB.
|
cobo
(Themenstarter)
Anmeldungsdatum: 19. Dezember 2020
Beiträge: 13
|
Ich glaube inzwische, dass es nur darum so lange ging weil irgend ein Prozess die Platte "festgehalten" hat. Ich habe dann statt mit gnome-disks die Sache mit gparted neu gestartet und irgendwie ging's dann: formatieren brauchte zwar durchaus eine Weile, aber nicht sehr lang. Kein Ahnung was das Partitionierungsschema ist, aber die Platte wurde als 5TB-Platte "erkannt" von gnome-disks und eine ebenso grosse Partition wurde erstellt: Ich hoffe jetzt mal, dass dieses Tool seinen Job versteht. Mein System, wo das Programm enthalten ist, ist Ubuntu 20.04 LTE, dürfte also einigermassen "aktuell" sein. Ich gehe mal davon aus, dass auch gnome-disks irgendwie die Formatierung geschafft hätte, wenn ich irgendwelche Prozesse gestoppt hätte oder was auch immer. Ist im Moment aber auch egal! Unterdessen ist BiT an der Arbeit, seit einer Stunde, und ich bin gespannt, wie es ausgeht...
|