Backup: Strategien - Programme - Erfahrungen

[GregorS]

Ich mag Borg ja eigentlich nicht so, ...

Ich mag bei Dingen, die mir besonders wichtig sind, grundsätzlich keine „Fremdprogramme“. Daher habe ich mir mein Backup-Script selbst geschrieben und dabei darauf geachtet, nur „alte und voraussichtlich langlebige 08/15-Tools“ wie rsync zu verwenden. So etwas anzustellen, macht zwar einmal viel Arbeit, aber wenn man es halbwegs schlau anstellt, hat man hinterher den absolut vollständigen Durchblick und ist im Notfall nicht auf andere(s) angewiesen.
Mein Backup-Script um Verschlüsselung und Upload irgendwo hin zu erweitern würde vielleicht zwei zusätzliche Zeilen mit ein/zwei Pipes erfordern.

Mach' sowas am besten selbst „zu Fuß“. Nur wenn Du es selbst machst, ist es wirklich so, wie Du es haben möchtest.

Gruß

Gregor

[schwedenmann]

Hallo


@heisenberg

Wo ich gerade am umdenken bin, ist die Verschlüsselung von Backups. Das mochte ich die ganze Zeit eher nicht. Aber ich denke im Cloud-Zeitalter ist es eigentlich angemessen grundsätzlich alles an sensiblen Daten, die irgendwo anders als im eigenen RZ oder dem heimischen Rechner liegen zu verschlüsseln.

Wenn es um daten von Kunden geht (also backup einens Kunden), dann würde ich auf jeden Fall verschlüsseln,wenn du das Backup in der Cloud speicherst. Wenn du das lokal vorhälst,würde ich es eher nicht machen.

ich weiß ich bin ambivalent,was backups und Verschlüsselung angeht, auch was backups und Komprimierung angeht. Obwohl da wohl kein Grund zu besteht,hätte ich immer Angst,das das dekomprimieren, Entschlüseln nicht klappt und genau dann,wenn das backup gebraucht wird. Ich mache auch aus denselben Gründen keine inkrementellen,differentielle Backups (wenn was klemmt,klappt der restore nicht).

Bei Verschlüsselung eines backups für Kunden würde ich außerdem die Paßphrase dem Kunden als Kopie übergeben.

mfg
schwedenmann

[heisenberg]

Mach' sowas am besten selbst „zu Fuß“. Nur wenn Du es selbst machst, ist es wirklich so, wie Du es haben möchtest.

Diese Strategie scheint wohl für Dich die passende gewesen zu sein. Was speziell hast Du da an Erfahrungen gemacht? Also negative Erfahrungen, bevor Du Dir diese Strategie angeeignet hast, als auch positive Erfahrungen, nachdem Du nach dieser Strategie verfährst?

Ich weiß ich bin ambivalent ...

Das geht mir da nicht anders. Ich habe Backupverschlüsselung bisher gemieden wie der Teufel das Weihwasser, weil mir ein funktionierendes Backup sehr wichtig ist und da möchte ich gerne alle unnötige Komplexität vermeiden. Aber Verschlüsselung ist - so wie ich das jetzt sehe - manchmal notwendig.

---

Ansonsten, was meine Strategie bzgl. Backup angeht, ist die ungefähr folgende:

Ich suche mir Software aus, die mir intuitiv gefällt und verabschiede mich davon, wenn ich merke, dass die sich nicht bewährt. Ich komme nicht auf die Idee, mir großartig selbst Skripte zu schreiben, sobald das einen gewissen Umfang überschreitet. Grundsätzlich könnte ich das natürlich alles auch selber schreiben, aber wenn ich sehe, was die Backupprogramme, die ich schätze (BackupPC, borg, rsnapshot), alles leisten und wie stabil und gereift diese Programme sind, dann sind das für mich die viel besseren Alternativen. Ich hätte nie den Nerv mich so lang andauernd damit zu beschäftigen und dementsprechend fehlerbehaftet wären meine Scripte dann.

Mir ist es wichtig, dass Backups absolut zuverlässig sind. Da hatte ich mit meiner Strategie bisher noch keine Reinfälle.

Ein Erlebnis in Bezug auf Backups bisher war, dass ich ein selbstgestricktes BackupSystem bei einem Kunden von irgend einem vorigen Admin gehabt habe. Der hat dann irgendwas mit rsync gemacht und das ganze dann mit zfs snapshots rotiert. Das fand der Admin bestimmt total cool. Doof ist halt, dass dieses Backupsystem keine Symlinks mitgesichert hat. Als ich das BackupSystem für eine volle Systemwiederherstellung brauchte, war das halt schon doof, dass da so 20-50 Symlinks gefehlt hatten. Das hat mich dann ca. 1 Tag gekostet, um das System in viel Kleinarbeit wieder zum Laufen zu bringen.

[cosinus]

Privat mach ich meine Backups auf externe Platten bzw normale Platten, die per HDD-Dock über USB angeschlossen sind. Dann etwa wöchentlich: von den wichtigsten Verzeichnissen wie etc, home oder var wird ein Archiv (SQUASHFS) gemacht und auf die ext. Platte geschrieben. Wenn ich Lust hab mach ich zusätzlich noch eine komplette Kopie meines Systemes mittels rsync

Im Büro: da unsere produktiven Server alle virtuell sind (VMWare ESXi) sichern wir alle VMs (Linux und Windows) täglich komplett mit Veeam Backup & Replication auf ein NAS. Monatlich noch ein Active Full Backup auf ein sekundäres NAS.

[schwedenmann]

Hallo

Momentan wird bei mir so gesichert.

Situation : 1 Hauptpc, 1 Multibootpc mit12 Linuxen und 1x backupserver mit freebsd, zfs und 2x 3Tb im mirror.

Jeden Tag wird vom HauptPC /etc und die Paketliste per anacron auf /shared (ist eine reine Datenpartition) gesichert.
Einmal im Momant sicher ich von einem 2.Linux auf dem Hauptpc aus sentimentalen Gründen das komplette / + /boot per dar auf /shared in 4,4GB Häppchen, dar erstellt ein Archiv.
Jeden 2. Tag sicher ich /home /shared sowie meine Musiksammlung per rsyncscript manuell auf eine 2.lokale Backupplatte,die Sicherung erfolgt manuell.
Jeden Sonntag sicher ich von dieser lokalen Platte per ssh + rsync auf den Freebsdserver. Somit habe ich quasi 3 backups von /home /shared und der mp3-Sammlung.
Den Multibootpc sicher ich auf eine 2.lokale Platte per
a. partclone + fsarchiver, sowie an einem anderen Tag noch mit borgbackup. Hier geht es mir ums testen der backupsoftware (partclone,fsarchiver und borgbackup) zwecks Schnelligkeit ud Zuverlässigkeit.


dbms sicher ich alle 2 Tage per
mariabackup
pgbackrest + pgmetrics (gibt eine Textadtei aus mit Systemdaten,dbs, konfiguration der DB, incl Datenbanken und tables-Übersicht)


Bareos und backuppc hatte ich auch mal getestet, wobei ich bei backuppc an der Konfiguration gescheitert bin, bei bareos hat alles geklappt,obwohl m.M. nach dessen Einrichtung wesentlich fehleranfälliger ist als bei anderen Backupsystemen. Was ich bei dieser art SW gut finde,ist die Speicherung und Darstellung der Sicherungen in der Datenbank,womit man eine schnellen Überblick über alle Sicherungen, Datum der Sicherung,etc. hat.



mfg
schwedenmann

[MSfree]

Warum braucht man so viele verschiedene Backupstrategien, daß es so viele verschiedene Programme geben muß?

• Vollständige Backups? Die benötigen sehr viel Platz, was die Anzahl der Backupgenerationen stark einschränkt.
• Inkrementelle Backups? Die sind Mist, weil sie Löschvorgänge nicht nachvollziehen können.
• Backup mit Hardlinks? Vereinen die Vorteile eines vollständigen Backups mit inkrementellen Backups, ohne deren Nachteile zu übernehmen. Allerdings dauert der Backupvorgang sehr lange und sind für sehr große Datenbestände ungeeignet.
• Snapshots? Funktionieren nur mit bestimmten Dateisystemen (teilweise problematisches Lizenzmodell). Sie sind aber verhältnismässig schnell gesichert.
• Versionsunabhängig? Das Backup wird möglicherweise erst zwei Debianreleases später benötigt. Da paßt dann vieles aus dem Busterbackup nicht zum aktuellen Bookworm.

Auch die Frage, was alles gesichert werden soltle, stellt sich.

• /etc? Konfigurationsdateien können sich mit dem nächsten OS-Release ändern und ggfls. inkompatibel werden. Mein letztes Aha-Elebnis war, daß bind9 nicht mehr nach /etc/bind schreiben darf und alles nach /var verlagert wurde.
• /home? Ähnlich wie unter /etc können Konfigurationsdateien und ~/.config inkompatibel werden und den Desktop sogar abstüzen lassen.
• /var? Kompatibilitätsproblemaitk wie /etc und /home. Das meiste hier ist sowieso eher temporärer Natur.

Die Zielsetzung:

• Vollständigkeit? Also wirklich jede Datei oder Trennung von System und Nutzerstorage?
• Geschwindigkeit des Backups
• Geschwindigkeit der Wiederherstellung
• Platzbedarf des Backups
• Einfachheit der Einrichtung, Wartung
• Wohin mit dem Backup? USB-Stick, externe Fastplatte, NAS, SAN, Cloud

rsync und seine davon abgeleiteten Abkömmlinge (z.B. rsnapshot) sind bis zu einer gewissen Datenmenge noch OK. Aber ein Seagate Corevault, das nicht einmal zu den besonders großen NAS/SANs gehört, will man mt rsync und Konsorten nicht mehr anfassen, wenn es mal mehr als 10% gefüllt ist.

Andererseits sind komplexe Methoden, wie snapshotfähige Dateisysteme, nicht für jeden und alles geeignet. Für Otto-Normalverbraucher, der seine Dateien per USB-Stick vom Desktoprechner zum 50cm daneben stehenden Laptop transportiert, sind diese Methoden viel zu kompliziert.

[cosinus]

Auch die Frage, was alles gesichert werden soltle, stellt sich.

Bei uns nicht. Die VMs müssen komplett gesichert werden, ohne Wenn und Aber. Das Vollbackup wird 1x monatlich gemacht, ansonsten nur inkrementelle Sicherungen.
Wenn was wiederhergestellt werden muss, hat man dann alle Optionen. Entweder einzelne Dateien oder Verzeichnisse oder eben ganze Dateisysteme bzw. die gesamte VM.

[heisenberg]

Zum Thema "alles sichern":

Ein Dienstleister eines Kunden hatte mal recht kurzfristig eine Anwendung programmiert. Irgendwann wurde das System dann mal neu gestartet und mit einem Mal waren die Daten weg. Was war geschehen? Der Dienstleister hatte die Daten unter /tmp abgelegt und nach dem Neustart waren die Daten dann eben weg und /tmp sichere ich natürlich nicht.

[GregorS]

Mach' sowas am besten selbst „zu Fuß“. Nur wenn Du es selbst machst, ist es wirklich so, wie Du es haben möchtest.

Diese Strategie scheint wohl für Dich die passende gewesen zu sein. Was speziell hast Du da an Erfahrungen gemacht? Also negative Erfahrungen, bevor Du Dir diese Strategie angeeignet hast, als auch positive Erfahrungen, nachdem Du nach dieser Strategie verfährst?

Wieso ich mir das angewöhnt habe, weiß ich gar nicht mehr. Vermutlich war es ein ganzes Bündel an Dingen. Ein Grund dafür, nicht zu packen oder gar zu verschlüsseln ist, dass ich so jederzeit ohne jedes Hilfsmittel auf die Daten zugreifen kann. „cp“ oder Drag-n-drop genügen. Und was den Platz angeht: Macht das denn wirklich noch irgendwo Probleme? So eine TB-HD koscht doch so gut wie nichts mehr.

... und dementsprechend fehlerbehaftet wären meine Scripte dann.

Bei mir traten nur wenige Fehler auf. Und jeder Fehler immer nur ein einziges Mal. Die ersten paar Wochen habe ich hier und da ein bisschen gefixt. Das letzte Mal ist viele Jahre her. Änderungen wie zusätzliche Rechner ausgenommen.

Mir ist es wichtig, dass Backups absolut zuverlässig sind. Da hatte ich mit meiner Strategie bisher noch keine Reinfälle.

Das Blöde ist nur, dass die Fehler immer da auftreten, wo man sie nicht erwartet. Shit happens nunmal. Ich stehe auf einfache Sachen, die mit Zuverlässigkeit und Langlebigkeit glänzen. Und ich stehe überhaupt nicht darauf, wenn mir irgendeine blöde Sache den Zugriff auf meine Daten erschwert oder gar Geld haben will.

Gruß

Gregor

[cosinus]

Der Dienstleister hatte die Daten unter /tmp abgelegt

und /tmp sichere ich natürlich nicht.

Da /tmp bei nächsten reboot ja eh weg ist, bind ich es immer als ramdisk ein.

[heisenberg]

Wieso ich mir das angewöhnt habe, weiß ich gar nicht mehr. Vermutlich war es ein ganzes Bündel an Dingen. Ein Grund dafür, nicht zu packen oder gar zu verschlüsseln ist, dass ich so jederzeit ohne jedes Hilfsmittel auf die Daten zugreifen kann. „cp“ oder Drag-n-drop genügen. Und was den Platz angeht: Macht das denn wirklich noch irgendwo Probleme? So eine TB-HD koscht doch so gut wie nichts mehr.

Ja. Für den Privatbereich ist mit Sicherheit sehr angenehm so. Dass die Dateien/Verzeichnisse einfach so da lagen, dass habe ich an rsnapshot auch sehr geschätzt.

Mir ist es wichtig, dass Backups absolut zuverlässig sind. Da hatte ich mit meiner Strategie bisher noch keine Reinfälle.

Das Blöde ist nur, dass die Fehler immer da auftreten, wo man sie nicht erwartet. Shit happens nun mal. Ich stehe auf einfache Sachen, die mit Zuverlässigkeit und Langlebigkeit glänzen. Und ich stehe überhaupt nicht darauf, wenn mir irgendeine blöde Sache den Zugriff auf meine Daten erschwert oder gar Geld haben will.

Ja. Da kann recht wenig kaputt gehen, wenn man's so einfach hält. Das ist prinzipiell eine sehr sichere Methode, mit der man sich wenig Probleme einhandeln kann, weil je einfacher desto weniger mögliche Fehler. Geld muss man dank ausreichend vieler und hochqualitativer OSS-Möglichkeiten auch gar nicht ausgeben.

---

Ich sehe da, dass ich im Vergleich zu Dir wenig private Langzeitarchivierung habe.

Gleichzeitig schätze ich auch im privaten Umfeld eine GUI, mit der ich schnell durch die verschiedenen Backups navigieren kann und mit wenigen Klicks auch etwas auf entfernten Systemen wiederherstellen kann und nicht erst wissen muss, wo ich das hinkopieren muss und auch wie (ssh? ftp?). Im beruflichen Umfeld sowieso. Da sind einfach viel mehr Backupsätze und viel mehr Server. Das geht da einfach viel schneller von der Hand.

Was den Plattenplatz angeht, da bin ich auch privat recht dankbar für die Deduplikation. Ich habe eigentlich gar keinen richtigen Privat-PC mehr. Zeitweise gar keinen und aktuell nur noch einen alten Laptop als Surfstation. D. h. der steht für Die Sicherung nicht mehr zur Verfügung. Die Backups, die ich mache gehen auf meinen VServer und da bin ich froh, dass ich dank Deduplikation nur noch ca. Faktor 15-20 weniger an Speicherplatz brauche, sonst müsste ich für mehr Speicher im VServer doch mehr Asche auf den Tisch legen. Und auf der Arbeit ist die benötigte Sicherungskapazität dann halt nicht im 3 stelligen GB-Bereich sondern im 3-stelligen TB-Bereich und da sind dass dann schon ein paar mehr Platten, die das braucht.

Weiterhin bin ich froh über Leistungsmerkmale, die ich mal eben so schnell zusammen klicken und anpassen kann. Das könnte ich mir nie alles in der Qualität selbst zusammenscripten. (Ich habe schon viel gescriptet. Ich bin da realistisch. ) Auch denke ich mir: Wenn es so tolle OSS-Programme gibt, die so viele nützliche Dinge können und das zuverlässig, wieso sollte ich die dann nicht nutzen?

Der grosse Unterschied zwischen Privatumfeld und Firmenumfeld ist dann halt das Geld und die Arbeitszeit von einem Admin kostet sehr viel davon. Bzw. die Resource Arbeitszeit des Admins ist auch irgendwo endlich. Und weiterhin: Wenn eine Software dort entsprechende Ersparnisse bzw. Vorteile bringt, dann darf die meiner Meinung nach auch das entsprechende Geld kosten.

[GregorS]

...
Der grosse Unterschied zwischen Privatumfeld und Firmenumfeld ist dann halt das Geld und die Arbeitszeit von einem Admin kostet sehr viel davon. Bzw. die Resource Arbeitszeit des Admins ist auch irgendwo endlich. Und weiterhin: Wenn eine Software dort entsprechende Ersparnisse bzw. Vorteile bringt, dann darf die meiner Meinung nach auch das entsprechende Geld kosten.

Da kann ich inzwischen nicht mehr so richtig mitreden. Im Umfeld einer Firma und wenn es um Geld geht (womöglich um irgendeinen juristischen Dünnsinn) hat man andere Prioritäten.

Und gegen eine GUI ist ansich ja auch nichts einzuwenden. Aber wirklich gut (für Backups) kann ich so etwas nur finden, wenn man die Wiederherstellung auch hinbekommen kann, ohne sich tage- oder wochenlang mit Doku beschäftigen zu müssen. Doku kann wirklich schlecht sein, v.A. Übersetzungen.

Gruß

Gregor

[cosinus]

wenn man die Wiederherstellung auch hinbekommen kann, ohne sich tage- oder wochenlang mit Doku beschäftigen zu müssen. Doku kann wirklich schlecht sein, v.A. Übersetzungen.

An für sich macht die Backupsoftware ja die Tests. Zumindest ob alles fehlerfrei kopiert/gesichert werden konnte. Dann müssen aber eigentlich noch regelmäßige Wiederherstellungstest gefahren werden.
Ein Nofallkonzept sollte aber aber so gestrickt sein, dass man nicht Wochen mit dem Studieren dieser Doku verplempert, das Wiederherstellen an sich kann ja ja schon sehr lange dauern.

[MSfree]

Und was den Platz angeht: Macht das denn wirklich noch irgendwo Probleme? So eine TB-HD koscht doch so gut wie nichts mehr.

Bei mir lungern 2.5TB auf dem Server, da kommt man mit einer 1TB-Platte nicht weit.

Ich habe auch den Anspruch, eine Backuphistory haben zu wollen. Im Zweifellsfall will ich das Backup vom 11. November 2021 zurückspielen können. Das ist inzwischen fast 700 Tage her, was den Backupumfang auf 1.8 Petabyte erhöhen würde, also 1800 Kost-ja-nüscht-1TB-Platten.

Ein Nofallkonzept sollte aber aber so gestrickt sein, dass man nicht Wochen mit dem Studieren dieser Doku verplempert, das Wiederherstellen an sich kann ja ja schon sehr lange dauern.

Siehe oben "Zielsetzung". Die 6 Punkte lassen sich nicht gleichzeitig erfüllen. Im Privatbereich ist es egal, ob das Restore 30 Minuten oder 3 Tage dauert. Haupsache, man kann den Datenbestand wiederherstellen. Im professionellen Umfeld muß die abgekachelte VM eines Kunden in 10 Minuten wiederhergestellt und hochgefahren sein. Entsprechend andere Strategien müssen gewählt werden, da muß dann schonmal die Backuphistory kurz gehalten werden, wenn man nicht 700 Vollkopien einer VM vorhalten kann und will.

Wie wichtig aber eine History sein kann, merkt man, wenn eine VM von einem Verschlüsselungstrojaner befallen wurde. Das letzte unverschlüsselte Backup ist unter Umständen 3 Tage alt. Mit nur einer täglichen Kopie ist man also längst nicht abgesichert.

Oft ist es ja nicht die Hardware, die das zeitliche segnet sondern menschliches Versagen. Wie einfach kommt man an eine versehentlich gelöschte Datei wieder ran? Bei einem rsync-Backup ist das ganz einfach, bei BTRFS/ZFS-Snapshots möglicherweise auch, bei ZIP/TGZ-Dateien schon wesentlich schwerer, von Bandlaufwerken eine Katastrophe, wenn man ein 18TB fassendes LTO9-Band komplett durchsuchen muß.

[cosinus]

Im professionellen Umfeld muß die abgekachelte VM eines Kunden in 10 Minuten wiederhergestellt und hochgefahren sein.

Das funktioniert aber nicht immer. Wenn die gesamte VM kaputt ist und man sie komplett wiederherstellen muss, dauert es so lange, bis alle Daten aus dem Backup aufs SAN zurücktransferiert sind. Wenn das mehrere TB sind kann das deutlich länger dauern als 10 Minuten.

Entsprechend andere Strategien müssen gewählt werden, da muß dann schonmal die Backuphistory kurz gehalten werden, wenn man nicht 700 Vollkopien einer VM vorhalten kann und will.

Dafür gibt es inkrementelle oder differentielle Backups. Selbstverständlich muss das Backup-NAS auch für inkrementelle Backups mit ausreichend großen Platten bestückt sein.

Mit nur einer täglichen Kopie ist man also längst nicht abgesichert.

Dann muss man öfter Backups machen oder weitere Features nutzen wie zB bei einem Windows-Fileserver Schattenkopien aktivieren.

Wie einfach kommt man an eine versehentlich gelöschte Datei wieder ran? Bei einem rsync-Backup ist das ganz einfach, bei BTRFS/ZFS-Snapshots möglicherweise auch, bei ZIP/TGZ-Dateien schon wesentlich schwerer, von Bandlaufwerken eine Katastrophe, wenn man ein 18TB fassendes LTO9-Band komplett durchsuchen muß.

Mit guter Backupsoftware ist das kein Problem. Da kann man per Dateibrowser sehen, was wiederhergestellt werden kann. Und dann stellt man selektiv einzelne Dateien oder Ordner wieder her. Oder man stellt eben die gesamte VM bzw. alle virtuellen Disks wieder her. Einzelne Dateien und Ordner auch per Schattenkopie wenn man wie oben schon erwähnt.
Bandlaufwerke nutzen wir schon seit fast 10 Jahren nicht mehr...

[heisenberg]

Also 10 Minuten für einen Restore bekomme ich bei mir nicht unbedingt hin. Mit einer dateibasierten Sicherung wie BackupPC schon gar nicht. Das war bei mir bisher bei mir glücklicherweise auch gar nicht nötig. So oft kommen da Totalausfälle auch gar nicht vor. Viel öfter kommt bei mr auf der Arbeit so etwas vor wie: "Das CMS ist kaputt. Für wieviele Tage haben Sie ein Backup? Setzen Sie das mal zurück!" oder "Wir brauchen die Datei bzw. das Verzeichnis xyz vom Datum abc".

Mit Dateisysytemsnapshots kommt man da aber schon hin, aber vermutlich auch nur in Verbindung mit einem physischen Datenbankbackup.

Mit Proxmox-Backup-Server (Der VM-Sicherungsserver für Proxmox Virtual Environment mit Deduplikation auf Blockebene und inkrementellen Image-Backups) komme ich da schon etwas näher dran.

Aber wirklich gut (für Backups) kann ich so etwas nur finden, wenn man die Wiederherstellung auch hinbekommen kann, ohne sich tage- oder wochenlang mit Doku beschäftigen zu müssen. Doku kann wirklich schlecht sein, v.A. Übersetzungen.

Ja. Natürlich. Aus Windows Zeiten erinnere ich mich da noch an das eher rudimentäre NTBackup. Das war nicht so toll und den ein oder anderen blöden Fehler hatte das auch noch. Da sind die renommierten Open Source Backupprogramme Gold dagegen. Und wenn man privat einfach entspannte Anforderungen hat, dann macht man mit seiner Zeit auch lieber etwas anderes, als sich in Backupprogramme einzuarbeiten. Ich würde, wenn ich wie noch vor vielen Jahren mal zu Hause ein dediziertes Backupsystem hätte (stromsparender Miniserver), möglicherweise auch BackupPC benutzen. Und ja, ab und an mal hatte ich da ein Problem, was gelöst werden musste. Aber das bis jetzt immer machbar.

Im Anwendungsgebiet Serversicherung scheint mir Veeam hier der absolute Platzhirsch im kommerziellen Umfeld zu sein - Ich nutze es nicht, da mir meine Lösungen ausreichen. Ansonsten kann Veeam schon viel und gut dementsprechend verlangen die auch ordentlich Kohle.

[cosinus]

Also 10 Minuten für einen Restore bekomme ich bei mir nicht unbedingt hin.

Es kommt drauf an was alles kaputt ist. Bei einer Katastrophe wie "Serverraum abgebrannt" wird niemand ernsthaft fordern, dass alles in 10 Minuten wieder laufen muss. Und wenn doch hätte man sich mehr Redundanz aufbauen müssen, nen zweiten Serverraum mit identischer Ausstattung. Aber was ist wenn ein Flugzeug ins Gebäude kracht und beide Serverräume zerstört?

[MSfree]

Aber was ist wenn ein Flugzeug ins Gebäude kracht und beide Serverräume zerstört?

Dann sollte man im Nachbargebäude einen dritte Serverraum haben. Äh, warte mal, da war doch mal was mit zwei Flugzeugen....

[cosinus]

Dann sollte man im Nachbargebäude einen dritte Serverraum haben. Äh, warte mal, da war doch mal was mit zwei Flugzeugen....

Den dritten Serverraum bildet man dann in einem RZ wie diesem hier ab

[heisenberg]

Was ich weiterhin, wie schon hier im Forum geschrieben nutze, sind Prüfscripte für die MySQL-Dumps bzw. Postgres-Dumps. Als kleine Scripte die prüfen, ob die Anzahl der Dumps auf dem System zu stark abweicht, die Dumps zu klein sind (ungültiges Archiv) oder zu alt. Was ich da noch hinzufügen könnte, wäre ein Flag-File für das Backup-Script, d. h. hat es ohne Fehler beendet oder nicht. In einer Privatumgebung mag da als Reaktion eine Mail passend sein. Bei mir ist es ein Zustand, den ich per Monitoring überwache.

Zusätzliches Programm, dass ich ebenso nutze, ist zfssnap. Gerade auf einem System wo sehr viele kleine Dateien sind (Maildir-User-Verzeichnisse). Dort nutzt zfssnap ein zfs send/receive um Daten effektiv und inkrementell an einen Backupplatz zu kopieren und anschließend Snapshots zu erstellen, die in einer festgelegten Rotation aufbewahrt werden.

[heisenberg]

Ich habe gerade einen Fall, wo ich Borg ganz gut einsetzen kann, weil...

• Nur ein zentraler Server (und ein paar Satelliten) vorhanden
• Möglichst einfacher Datenspeicher (Hetzner StorageBox)

Da finde ich das brauchbar. Ich nutze statt Borg den Wrapper borgmatic. Das ist das rundum-glücklich Paket:

• Rotationen
• Datenprüfungen - seeehr wichtig! (mit mehreren Optionen inkl. Testwiederherstellung nach /dev/null)
• Ein-/Ausschlußmuster
• Verschlüsselung

Zusätzlich gibt's eine Textdatei, wo der exportierte Repo-Key drin ist, sowie die Passphrase und die Config. Das wird dann separat gehalten und fertig! Funktioniert gut.

Nachtrag

Als halbwegs brauchbarer GUI-Ersatz zum Wiederherstellen für Nicht-Experten dient mir da ein Mini-Script, in der Art:

Code: Alles auswählen

#!/bin/bash

# --- mount repository with borgfs 
borgfs --options <repository> <mountpoint>

# --- start midnight commander
cd <mountpoint>
mc

# --- unmount after mc exit
cd -
umount <mountpoint>

[pferdefreund]

Ich benutze tar und mache einfach ein volles Backup ausser sys run und proc. Hat bisher immer gut funktioniert. Nach dem restore mit system rescue cd die 3 Ordner anlegen, Lilo ausführen , neu starten und alles ist wieder gut. Datenbanken und ähnliches natürlich vor dem Backup stoppen wegen der Konsistenz.
Gab damit noch nie Propleme und bei ca 5 GB ist der Aufwand überschaubar.

[cosinus]

Lilo ausführen

LiLo?
Ist dieser alte Bootloader nicht schon längst tot? Standard ist doch GNU GRUB. Und als Alternative für reine UEFI-Systeme gibt es systemd-boot (auch als Gummiboot bekannt )

[MSfree]

Ich benutze tar und mache einfach ein volles Backup ausser sys run und proc. Hat bisher immer gut funktioniert.

Das wären bei meinem Heimserver 2.2TB, was rund 8 Stunden dauern würde.

Nach dem restore mit system rescue cd die 3 Ordner anlegen, Lilo ausführen

Lilo? Geht das überhaupt mit 64Bit und UEFI? Die Entwicklung von elilo wurde 2014 eingestellt.

Gab damit noch nie Propleme und bei ca 5 GB ist der Aufwand überschaubar.

Bei 5GB ja, bei 2.2TB braucht man etwas effizienteres.

Aber genau das ist es, warum es nicht die Backupmethode geben kann. Je nach Datenmenge, Zielsetzung, Anforderungen an möglichst geringe Downtimes, Backupinterval... muß man sich das geeignete Mittel suchen.

[heisenberg]

Wo man bei Borg aufpassen muss, ist, dass das Archiv nicht aus versehen "gesperrt" bleibt. Wenn man z. B. vergisst, ein mittels borgfs eingehängtes Archiv wieder auszuhängen. Sonst laufen die Backups halt einfach nicht mehr.