LarsT schrieb:
Bisher habe ich einfach "täglich" ein "rsync -az" jede Mitternacht DATEN auf STORAGE gemacht.
Das ist nun wirklich die rudimentärste Backuplösung, aber ein Backup ist besser als keins 😉.
Aber nun ist mir folgendes zu Ohren gekommen:
Es ist sehr selten - aber durchaus vorgekommen - dass durch einen Defekt im RAID-Controller die Daten zerstört wurden. Sprich CRC Fehler und I/O Fehler.
Wenn dieser Fall eintreten sollte - wäre mein Backup aber ja auch recht fix kaputt.
Komischer Serveranbieter bei dem das auftritt, da würde ich wohl schnell wechseln wollen. Im allgemeinen sollte das aber selten bis gar nicht auftreten, da du das auch nur vom hörensagen kennst gehen wir mal davon aus das Risiko dafür eher bei 0,01% liegt oder so. Das wäre für mich auf jeden Fall nicht der ausschlaggebende Grund die Backupstrategie zu erweitern. Sinnvoll ist eine solche aber auf jeden Fall.
Nehmen wir mal folgende Situation an:
Abends um 22 Uhr fällt der RAID Controller aus und macht die Daten kaputt (aber noch lesbar).
Nachts um 24 Uhr kopiert das Script die kaputten Daten in die Sicherung. =⇒ Die Sicherung ist dann auch kaputt.
Jain, rsync kopiert ja nur geänderte Dateien. Bei dem verwendeten Modus guckt er nur auf Zeitstempel. Wenn die nicht angepackt wurden dann wird die Datei nicht kopiert und ist im Backup noch ganz. Geänderte und kaputt übertragene Dateien wären dann aber nicht mehr wiederherstelbar.
Daher dachte ich vllt: "daily + 1x weekly"?
Oder ggf. sogar in monatlich, bzw ein Backup, welches nie wieder angerührt wird?
Du hast rsnapshot ja schon ins Spiel gebracht. Das macht das alles von Haus aus. Nochmal in Kurz:
Hardlink-Kopie der letzten Sicherung erstellen: Spart Platz, da die Daten hinter den Dateien sich ja nicht ändern und demzufolge auch nicht doppelt gespeichert werden müssen
rsync auf die Kopie → Die geänderten Dateien werden kopiert, der Rest bleibt unangetastet
Damit hättest du dann deine alten Sicherungen die alle (!) nicht mehr angepackt werden, bzw. nur um sie, wenn sie zu alt sind, zu löschen. Normalerweise hält man Sicherungen in folgendem Schema vorrätig: (Optional, ich mache es z.B. für E-Mails: Stündliche für einen Tag), Täglich für eine Woche, Wöchentlich für einen Monat, Monatlich für ein Jahr, alle Jahressicherungen (wobei man sich da überlegen kann ob man Sicherungen >x Jahre noch braucht).
Und wie sieht es hiermit aus:
Mir wurde geraten, ggf. vorher Dovecot/Postfix herunterzufahren (damit nicht Daten während der Sicherung geändert werden und die Sicherung somit unbrauchbar wird)
Außerdem hieß es, Storage-Space erst kurz vor Backup mounten und dann wieder unmounten?
Jain. Die sicherste Variante ist es, aber in meinen Augen overkill (Ich tue es nicht und hatte bei 2 restores bisher keine Probleme damit). Im Normalfall speichert der Postfix die Daten ja nicht selbst in den E-Mail Fächern (und /var/spool sicherst du vermutlich nicht) sonder leitet sie direkt an den Dovecot weiter, der sie dann final auf Platte schreibt. Aus der Dovecot Maildir-Spec:
* ~/Maildir/new
, ~/Maildir/cur
and ~/Maildir/tmp
directories contain the messages for INBOX. The tmp
directory is used during delivery, new messages arrive in new
and read shall be moved to cur
by the clients.
Anmerkung: Das Kopieren nach cur
erfolgt dabei mittels hardlinking der Dateien in tmp
, soll heißen die Daten sind schon da. Dabei kann also keine Datenkorruption durch unvollständig geschriebene Dateien auftreten.
Soll heißen: Einfach unterhalb der Postfix-Maildirs die tmp
verzeichnisse auslassen und das Problem erledigt sich von selbst.
Ich rate dir einfach mal zu rsnapshot, unter anderen weil ich es selbst seit >1Jahr im Einsatz habe.