Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > ger.ct > #630504

Re: Backup, dateibasiert, volumenuebergreifend

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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