Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ulrich D i e z <ud.usenetcorrespondence@web.de> |
|---|---|
| Newsgroups | ger.ct |
| Subject | Re: Backup, dateibasiert, volumenuebergreifend |
| Date | 2024-11-23 20:22 +0100 |
| Message-ID | <vhta0j$1b5bt$1@solani.org> (permalink) |
| References | <5600555409.a7aba743@duerrhauer.de> |
Christian Dürrhauer schrieb: > Hallo, > > ich habe eine Mediensammlung von TV-Aufnahmen, die mittlerweile in der Größe > mindestens einen Datenträger voll und einen Teil eines nächsten Mediums > umfassen würde. > > Ich habe mir bisher "rsnapshot" ausgesucht, aber der kann das > volumenübergreifend wohl nicht. > > Wie sichert Ihr denn? Ich arbeite inzwischen unter Linux mit ZFS-Volumes. <https://de.wikipedia.org/wiki/ZFS_(Dateisystem)> Meine Dateien liegen in drei zusammen eine RAID-1-Redundanzgruppe bildenden ZFS-Volumes. Derzeit besteht ein ZFS-Volume der ZFS-Redundanzgruppe bei mir aus einer einzigen Festplatte. Ein ZFS-Volume einer ZFS-Redundanzgruppe kann aber auch aus mehreren physischen Datenträgern bestehen. Dieser Umstand könnte ZFS für dich interessant machen. Auf diese Weise ist es nicht mehr gar so wichtig, explizit Datensicherung bzw Backup zu fahren, da der Datenbestand physisch dreimal da ist und ggfs ein defekter physischer Datenträger gegen einen intakten ausgewechselt werden kann wonach sich alles mehr oder weniger automatisch synchronisiert. Ich fahre aber trotzdem ab und zu Backups ZB vor anstehenden Änderungen am Betriebssystem einer Maschine. Solche Backups gehen - je nach Art der Datensicherung - per rsync oder per CloneZilla an eine Freigabe eines Samba-Servers, bei dem der Datenbestand ebenfalls als eine solche ZFS-RAID-1-Redundanzgruppe organisiert ist. Die Maschine mit dem Samba-Server ist gleichzeitig ein PXE-Server, der die anderen Maschinen im lokalen Netzwerk wecken und mit einem Boot-Image versorgen kann, welches deren Backup oder das Zurückschreiben eines Backups fährt. Auf diese Weise wird weder fürs Backup noch fürs Zuückschreiben das auf der zu sichernden Maschine installierte Betriebssystem gebraucht, sodass es bezogen aufs Backup oder Zurückschreiben des Backup nichts ausmacht wenn das Betriebssystem, das auf der zu sichernden bzw wiederher- zustellenden Maschine installiert ist, nicht funktioniert. Die Maschine mit dem Samba-Server schalte ich nur ein wenn das lokale Netzwerk nicht mit dem Internet verbunden und keine andere Maschine des lokalen Netzwerks vom auf ihr selbst installierten Betriebssystem hochgefahren ist. Dies soll ein Korrumpieren der für Backup und fürs Zurückspielen verwendeten Maschinerie erschweren. Als Besonderheit achte ich darauf, dass bei dem Samba-Server, auf dem die Backups gespeichert werden, immer nur zwei der drei ZFS-Volumes der ZFS-Redundanzgruppe gleichzeitig eingeschaltet sind. Das heißt zwar, dass der Datenbestand aller Volumes der ZFS-Redundanzgruppe nie auf einen Rutsch synchronisiert wird, sondern immer auf "zwei Rutsche". Dafür ist aber das Risiko ausgeschaltet, dass der Datenbestand gleich auf allen ZFS-Volumes der ZFS-Redundanzgruppe korrumpiert ist, wenn beim Synchronisieren etwas schief geht. Mit freundlichem Gruß Ulrich
Back to ger.ct | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Backup, dateibasiert, volumenuebergreifend Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2024-11-23 10:59 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-23 11:15 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-24 14:50 +0100
Re: Backup, dateibasiert, volumenuebergreifend Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-11-24 16:02 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-25 09:55 +0100
Re: Backup, dateibasiert, volumenuebergreifend Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-11-26 17:35 +0100
Re: Backup, dateibasiert, volumenuebergreifend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-25 09:50 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-23 12:00 +0100
Re: Backup, dateibasiert, volumenuebergreifend Joerg Walther <joerg.walther@magenta.de> - 2024-11-23 15:49 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-23 20:22 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-23 21:37 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-24 15:26 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-24 16:21 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-25 22:26 +0100
Re: Backup, dateibasiert, volumenuebergreifend "Wendelin Uez" <wuez@online.de> - 2024-11-27 13:13 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-11-27 14:00 +0100
Re: Backup, dateibasiert, volumenuebergreifend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-11-27 17:03 +0100
Re: Backup, dateibasiert, volumenuebergreifend Ruediger Lahl <ruediger.lahl@gmx.de> - 2024-11-23 16:51 +0100
Re: Backup, dateibasiert, volumenuebergreifend Frank Nitzschner <nospam@nitzschner.de> - 2024-11-24 09:50 +0100
csiph-web