ext.HDD welches Dateisystem für Backup
ext.HDD welches Dateisystem für Backup
Hallo Debianer,
ich habe ein folgendes vorhaben und zwar
ich habe zwei 12TB externe Festplatten welche als Backup genutzt werden sollen, kein RAID.
Da ich für Windows auch eine Lösung brauche, muss eine ext.HDD mit dem Dateisystem NTFS vorliegen.
Die HDDs werden nicht über bestimmt mount Parameter eingebunden, "plug and play hard drive"
Jetzt zur meine Frage, bei der zweite ext.HDD bin ich mir mit dem Dateisystem nicht sicher, denke da EXT4 oder BTRFS.
Welche würdet Ihr nehmen und warum?
ich habe ein folgendes vorhaben und zwar
ich habe zwei 12TB externe Festplatten welche als Backup genutzt werden sollen, kein RAID.
Da ich für Windows auch eine Lösung brauche, muss eine ext.HDD mit dem Dateisystem NTFS vorliegen.
Die HDDs werden nicht über bestimmt mount Parameter eingebunden, "plug and play hard drive"
Jetzt zur meine Frage, bei der zweite ext.HDD bin ich mir mit dem Dateisystem nicht sicher, denke da EXT4 oder BTRFS.
Welche würdet Ihr nehmen und warum?
Zuletzt geändert von Stas am 29.12.2020 22:30:11, insgesamt 2-mal geändert.
Debian 12 || Proxmox 8 || i7-4790 || GTX 970
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: ext.HDD welches Dateisystem für Backup
exFat ist jetzt auch im linux kernel, das heist du koenntest die Windows platte dann auch performant unter linux benutzen. So in der Theorie. Ich habe selber exFat noch nicht getestet.Stas hat geschrieben:19.12.2020 13:18:18Da ich für Windows auch eine Lösung brauche, muss eine ext.HDD mit dem Dateisystem NTFS vorliegen.
Ich wuerde BTRFS benutzten. Snapshots sind der geielste Schiesse seit dem es geschnitten Brot gibt.Stas hat geschrieben:19.12.2020 13:18:18Jetzt zur meine Frage, bei der zweite ext.HDD bin ich mir mit dem Dateisystem nicht sicher, denke da EXT4 oder BTRFS.
Welche würdet Ihr nehmen und warum?
Und du hast auch checksummen aller deiner Daten und kannst sehen wenn etwas korrupt ist.
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
- jph
- Beiträge: 1053
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: ext.HDD welches Dateisystem für Backup
Dem kann ich zustimmen. Mit btrfs send/receive lassen sich richtig coole Sachen anstellen – siehe btrbk.Lord_Carlos hat geschrieben:19.12.2020 14:05:59Ich wuerde BTRFS benutzten. Snapshots sind der geielste Schiesse seit dem es geschnitten Brot gibt.
Und du hast auch checksummen aller deiner Daten und kannst sehen wenn etwas korrupt ist.
Für Windows gibt es einen btrfs-Treiber: https://github.com/maharmstone/btrfs. Vielleicht eine Alternative zu NTFS auf der ersten Platte?
Re: ext.HDD welches Dateisystem für Backup
Danke Euch!
Genau das habe ich mir gerade auch angeschaut:
Das mit btrfs-Treiber funktioniert gut unter Win10.
Genau das habe ich mir gerade auch angeschaut:
Habe gerade das csum Verhalten unter Virtualbox angeschaut, Bitfehler(HDD.vdi manipuliert mit HEX-Editor) werden erkannt cooljph hat geschrieben:19.12.2020 17:44:47Dem kann ich zustimmen. Mit btrfs send/receive lassen sich richtig coole Sachen anstellen – siehe btrbk.Lord_Carlos hat geschrieben:19.12.2020 14:05:59Ich wuerde BTRFS benutzten. Snapshots sind der geielste Schiesse seit dem es geschnitten Brot gibt.
Und du hast auch checksummen aller deiner Daten und kannst sehen wenn etwas korrupt ist.
Für Windows gibt es einen btrfs-Treiber: https://github.com/maharmstone/btrfs. Vielleicht eine Alternative zu NTFS auf der ersten Platte?
Das mit btrfs-Treiber funktioniert gut unter Win10.
Debian 12 || Proxmox 8 || i7-4790 || GTX 970
Re: ext.HDD welches Dateisystem für Backup
Hallo noch ne frage zu BTRFS.
Ich habe jetzt das Btrfs-Dateisystem über gparted für die externe 12TB-HDD erstellt.
- Es wir so gesehen eine plug and play hard drive!
- zusätzliche Mount-Optionen wird es nicht geben
- kein subvolume wird erstellt
- es soll an verschiedene Linux-Distributionen angeschlossen werden (Btrfs Werkzeug ist vorhanden)
- snapshot werden über Copy & Paste erstellt
Seht Ihr bis hier ein Problem
Und ne Frage zu den Befehlen, welche sollte man hin und wieder durchführen?
Eins meiner wichtigen Befehle wird auf jeden Fall btrfs check --check-data-csum sein!
Oo habe doch was gefunden https://wiki.debianforum.de/Btrfs
Ich habe jetzt das Btrfs-Dateisystem über gparted für die externe 12TB-HDD erstellt.
- Es wir so gesehen eine plug and play hard drive!
- zusätzliche Mount-Optionen wird es nicht geben
- kein subvolume wird erstellt
- es soll an verschiedene Linux-Distributionen angeschlossen werden (Btrfs Werkzeug ist vorhanden)
- snapshot werden über Copy & Paste erstellt
Seht Ihr bis hier ein Problem
Und ne Frage zu den Befehlen, welche sollte man hin und wieder durchführen?
Eins meiner wichtigen Befehle wird auf jeden Fall btrfs check --check-data-csum sein!
Oo habe doch was gefunden https://wiki.debianforum.de/Btrfs
Debian 12 || Proxmox 8 || i7-4790 || GTX 970
- jph
- Beiträge: 1053
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: ext.HDD welches Dateisystem für Backup
Knapp daneben ist auch vorbei. Von btrfs check lässt man im Allgemeinen besser die Finger. Die Prüfsummen werden mit btrfs scrub validiert. Das ist auch das Tool der Wahl, das man bspw. nach einem unsauberen Shutdown (Strom weg etc.) verwendet.Stas hat geschrieben:25.12.2020 21:36:07Eins meiner wichtigen Befehle wird auf jeden Fall btrfs check --check-data-csum sein!
Nachtrag: ich sehe ein mögliches Problem bei „Snapshots werden über Copy & Paste erstellt“. Was meinst du damit?
Re: [gelöst] ext.HDD welches Dateisystem für Backup
Mit "Snapshots werden über Copy & Paste erstellt" meine ich,
Ich kopiere die Daten/Ordner in ein anderes Verzeichnis(Sicherung), d.h. sofern man was aus versehen löscht, bleibt es in dem Ordner Sicherung erhalten, aber beim Kopieren wird kein Platzverbrauch.
btrfs check lässt man im Allgemeinen besser die Finger, warum das, ich dachte endlich kann ich die HDD eigenständig Testen.
Also sollte ich das nutzen ja; sudo btrfs scrub status -R /dev/sdb1
Ich kopiere die Daten/Ordner in ein anderes Verzeichnis(Sicherung), d.h. sofern man was aus versehen löscht, bleibt es in dem Ordner Sicherung erhalten, aber beim Kopieren wird kein Platzverbrauch.
btrfs check lässt man im Allgemeinen besser die Finger, warum das, ich dachte endlich kann ich die HDD eigenständig Testen.
Also sollte ich das nutzen ja; sudo btrfs scrub status -R /dev/sdb1
Zuletzt geändert von Stas am 29.12.2020 23:05:23, insgesamt 2-mal geändert.
Debian 12 || Proxmox 8 || i7-4790 || GTX 970
Re: ext.HDD welches Dateisystem für Backup
Das Testen/Überprüfen der Prüfsummen macht man mit btrfs-scrub, währendessen Dateisystem auch gemountet sein darf und muss. Mit
prüft man Beispielsweise ohne dass bei Fehlern etwas repariert wird (-r), das ganze läuft im Vordergrund (-B) und hinterher wird eine Zusammenfassung für jedes am Dateisytem beteiligte Gerät angezeigt (-d). (Statt dem Pfad kann man auch eine Gerätedatei angeben.)
btrfs check dagegen ist weniger für das Prüfen der Prüfsummen sonder das der Dateisystemstrukturen. Dabei darf das Dateisystem nicht gemountet sein und es kann auch repariert werden, wobei man da besser vorher ein Image des Dateisystems macht, weil es viele Optionen gibt und auch einiges schief gehen kann.
Ich würde mir an deiner Stelle auch noch einmal überlegen ob du nicht doch Snapshots nutzen willst - die sind wirklich genial. Ich mache es zum Beispiel so, dass ich auf dem Zielmedium für ein Backup ein eigenes Subvolume habe. Dann synchronisiere ich mit rsync das Quelldatenverzeichnis mit dem Subvolume und lege gleich nach der Synchronisation einen read-only-Snapshot von diesem Subvolume an.
Su muss rsync immer nur die seit dem letzten Mal geänderten Dateien übertragen und ich habe mit den read-only-Snapshots beliebig viele nicht irrtümlich veränderbare Backup-Versionsstände, bei möglichst wenig Platzverbrauch.
Das Ganze mache ich mit einem Shellskript, das die Zahl der read-only-Snapshots auch etwas ausdünnt je weiter sie in der Vergangenheit liegen.
(btrfs send/receive wäre natürlich noch effizienter, aber dazu müssten die Quelldaten auch auf entsprechenden Subvolumes liegen und ich will auch Dinge sichern, die nicht einmal auf einem btrfs-Dateisystem liegen und spiele auf meinem System mit den Quelldaten viel zu viel mit den Subvolumes als dass ich das vernünftig nutzen könnte.)
Code: Alles auswählen
btrfs scrub start -B -d -r /mnt/btrfs-mountpoint
btrfs check dagegen ist weniger für das Prüfen der Prüfsummen sonder das der Dateisystemstrukturen. Dabei darf das Dateisystem nicht gemountet sein und es kann auch repariert werden, wobei man da besser vorher ein Image des Dateisystems macht, weil es viele Optionen gibt und auch einiges schief gehen kann.
Ich würde mir an deiner Stelle auch noch einmal überlegen ob du nicht doch Snapshots nutzen willst - die sind wirklich genial. Ich mache es zum Beispiel so, dass ich auf dem Zielmedium für ein Backup ein eigenes Subvolume habe. Dann synchronisiere ich mit rsync das Quelldatenverzeichnis mit dem Subvolume und lege gleich nach der Synchronisation einen read-only-Snapshot von diesem Subvolume an.
Su muss rsync immer nur die seit dem letzten Mal geänderten Dateien übertragen und ich habe mit den read-only-Snapshots beliebig viele nicht irrtümlich veränderbare Backup-Versionsstände, bei möglichst wenig Platzverbrauch.
Das Ganze mache ich mit einem Shellskript, das die Zahl der read-only-Snapshots auch etwas ausdünnt je weiter sie in der Vergangenheit liegen.
(btrfs send/receive wäre natürlich noch effizienter, aber dazu müssten die Quelldaten auch auf entsprechenden Subvolumes liegen und ich will auch Dinge sichern, die nicht einmal auf einem btrfs-Dateisystem liegen und spiele auf meinem System mit den Quelldaten viel zu viel mit den Subvolumes als dass ich das vernünftig nutzen könnte.)
Zuletzt geändert von smutbert am 30.12.2020 00:54:33, insgesamt 1-mal geändert.
Re: ext.HDD welches Dateisystem für Backup
Danke das Hilft mir
Debian 12 || Proxmox 8 || i7-4790 || GTX 970
- jph
- Beiträge: 1053
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: [gelöst] ext.HDD welches Dateisystem für Backup
Wenn du eine Datei aus Ordner A nach B kopierst, dann belegt die Kopie mitunter doch Platz. Es wird nicht immer eine Reflink-Kopie erzeugt. Echte Snapshots zu erzeugen (btrfs subvolume snapshot, auf Wunsch RO mit btrfs subvolume snapshot -r) ist sicherer, einfacher und schneller als Kopieren. Mit entsprechenden Tools lässt sich das sogar automatisieren. Aber unabhängig davon – dass Kopien/Snapshots auf der gleichen Platte keine Sicherung sind, ist dir klar?Stas hat geschrieben:29.12.2020 22:25:34Mit "Snapshots werden über Copy & Paste erstellt" meine ich,
Ich kopiere die Daten/Ordner in ein anderes Verzeichnis(Sicherung), d.h. sofern man was aus versehen löscht, bleibt es in dem Ordner Sicherung erhalten, aber beim Kopieren wird kein Platzverbrauch.
Wenn du eine automatische In-Band-Deduplizierung willst, dann bist du möglicherweise bei ZFS besser aufgehoben.
- jph
- Beiträge: 1053
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: ext.HDD welches Dateisystem für Backup
Das Problem kenne ich und habe es folgendermaßen gelöst: das Backup an sich wird von borgbackup erledigt. Das dedupliziert intern und damit auch über Geräte-/Dateisystemgrenzen hinweg. Das Borg-Repositiory liegt in einem eigenen Subvolume, das über btrbk auf einen anderen Rechner geschickt wird.smutbert hat geschrieben:29.12.2020 22:51:20(btrfs send/receive wäre natürlich noch effizienter, aber dazu müssten die Quelldaten auch auf entsprechenden Subvolumes liegen und ich will auch Dinge sichern, die nicht einmal auf einem btrfs-Dateisystem liegen und spiele auf meinem System mit den Quelldaten viel zu viel mit den Subvolumes als dass ich das vernünftig nutzen könnte.)
Re: ext.HDD welches Dateisystem für Backup
Verstehe ich das recht, dass du damit mit borgbackup schon ein Backup hast von dem du mit btrbk noch weitere Backups mit btrbk erstellst?
Oder betrachtest du das Borg-Repository (ich muss mir einmal ansehen wie borg arbeitet) nur als Zwischenschritt und nicht als Backup?
Oder betrachtest du das Borg-Repository (ich muss mir einmal ansehen wie borg arbeitet) nur als Zwischenschritt und nicht als Backup?
- jph
- Beiträge: 1053
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: ext.HDD welches Dateisystem für Backup
Das Borg-Repository liegt lokal auf meinem Fileserver, damit die Container etc. ihre Backups schnell „abkippen“ können. btrbk schickt die anschließend weiter, damit sie im Sinne eines „echten Backups“ den Rechner und das Haus verlassen. Das dauert über DSL schon mal eine Weile. So gesehen ist das lokale Borg-Repository nur ein Zwischenschritt.
Sowohl BorgBackup als auch btrbk haben eigene Policys, wie lange Backups/Generationen aufzubewahren sind. Das ist in gewisser Weise doppelt gemoppelt. Ich habe die Aufbewahrungsfristen von btrbk sehr kurz gefasst, weil ich die Aufbewahrung über Borg steuern will.
Sowohl BorgBackup als auch btrbk haben eigene Policys, wie lange Backups/Generationen aufzubewahren sind. Das ist in gewisser Weise doppelt gemoppelt. Ich habe die Aufbewahrungsfristen von btrbk sehr kurz gefasst, weil ich die Aufbewahrung über Borg steuern will.