• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Backup + Restore Best Practice für eingerichtete Installation?

mr44er

Well-Known Member
Themenstarter #1
Ich wollte mal, um Denkanstöße zu bekommen, in die Runde fragen, wie ihr fertig konfigurierte Installationen wegsichert.

Vorab: Es geht nicht um die Urlaubsbilder, sondern explizit um die reine, fertig konfigurierte FreeBSD-Installation mit jails, eigenem Kernel und allem pipapo.

Bisher hatte ich noch keinen solchen Maximalcrash, da ich mit ZFS genügend Redundanz druntergelegt habe. Falls doch mal der worst case kommt, habe ich alle configs gesondert abgespeichert und würde einfach auf einer neuen Maschine installieren. Damit einen restore fahren würde aber lange dauern.

Für Windows auf Blech hab ich in grauer Vorzeit Acronis True Image liebgewonnen. BootCD rein, Quellplatte auf Zieldatei (inkl. Kompression, yeah!) und fertig war die Laube.

Wie wäre ein vergleichbarer Ansatz unter FreeBSD mit Bordmitteln dazu, wenn man mit möglichst mit kurzer Downtime restoren will? Quasi wie bei Acronis Inhalt von Backupdatei auf neue Platte schreiben und booten.

In meinem Gedankenspiel würde ich Jails und Datenbanken stoppen. Jetzt mit dd agieren. Aber Partitionen nehmen...oder doch das ganze device? Nicht so sinnig, wenn man geli und ZFS nutzt.
Oder spiegel ich besser zroot wohin, installiere FreeBSD frisch und überschreibe zroot mit jenem vom Backup und reboote dann?

Bei Totalausfall der Festplatten und anschließendem Tausch gegen neue fährt das System sicher hoch nach einem Restore. Ich kann mir aber vorstellen, dass eine komplett andere Maschine mit diesem Backup nur mit dem GENERIC-Kernel hochfährt. Wie sieht das konkret aus?

Noch eine andere Frage zu Hardware: An meinem Server habe ich nur USB2.0 Slots und meine externe Fesplatte hat einen USB3-Anschluß. Die vertragen sich untereinander aber nicht, gibt Fehlermeldungen (kein Saftmangel, das Gehäuse hat ein externes NT). An anderen PCs mit USB2 oder 3 läuft die Platte problemlos.
Kann mir jemand eine unter FreeBSD laufende USB3.0 PCI-E-Karte empfehlen, die man mit gutem Gewissen in einen Server packen kann? Die Geschwindigkeit von USB3 brauche ich nicht, würde mir dann einfach ein Gehäuse mit USB2 holen und die Platte umbauen.
 
Zuletzt bearbeitet:

Andy_m4

Well-Known Member
#2
Warum nicht dateiweises kopieren? Dieser ganze Image-Kram ist zwar unter Windows sehr beliebt, aber ich glaube auch nur deshalb, weil die gute alte Dateikopie nicht wirklich gut funktioniert.
Natürlich heißt Dateikopie nicht, Du sollst cp nehmen (auch wenn das ginge). Aber Du kannst jedes dateibasierte Backup-Tool nehmen (wie z.B. restic).
Klar musst Du gucken, wie Du das Partitionsschema aufbaust. Aber das kann man ja per Skript erledigen lassen in dem man all die Befehle reinstellt, die man beim Erstinstall gemacht hat.
Dann hast Du nur noch das "Problem" den Bootloader zu installieren bist aber dann durch. Vor allem aber lässt sich so ein Backup auch gut auf andere Rechner übertragen. Wenn Du ein Recovery machen musst, weil ne Festplatte ausgefallen ist nützt Dir im ersten Schritt (wo Du womöglich keine Festplatte) ja kein Backup-Image, was irgendwie 3 Festplatten voraussetzt. Da willst du erstmal nur ein lauffähiges System auch wenn das vielleicht bedeutet, dass Du (noch) nicht alles wiederherstellst.
 

mr44er

Well-Known Member
Themenstarter #3
Warum nicht dateiweises kopieren?
Da spricht nix dagegen.

Ich bekomm nur immer so ein ungutes Gefühl aka kalter Schauer über den Rücken, wenn ich restoren muß. Ich hab nichts Missionskritisches am Laufen und ich kann zehn Kaltbackups an div. Orten haben und Downtime ist auch eigentlich auch egal - an dem blöden Gefühl kann ich nix ändern. Weiß nicht, wie es dir da geht. :)
Um dem ein wenig entgegenzuwirken, wollte ich die Schritte beim Restoren auf ein Minimum runterschrauben.

Aber das kann man ja per Skript erledigen lassen in dem man all die Befehle reinstellt, die man beim Erstinstall gemacht hat.
Jep, mit dem Installer bekommt man nicht die Möglichkeit den Pool so zu konfigurieren, da geht nur die Einfachspiegelung mit n-Stripes:
Code:
pool: zroot
state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Fri Nov  2 08:32:04 2018
config:

    NAME            STATE     READ WRITE CKSUM
    zroot           ONLINE       0     0     0
      mirror-0      ONLINE       0     0     0
        ada0p3.eli  ONLINE       0     0     0
        ada1p3.eli  ONLINE       0     0     0
        ada2p3.eli  ONLINE       0     0     0
      mirror-1      ONLINE       0     0     0
        ada3p3.eli  ONLINE       0     0     0
        ada4p3.eli  ONLINE       0     0     0
        ada5p3.eli  ONLINE       0     0     0
Dann hast Du nur noch das "Problem" den Bootloader zu installieren bist aber dann durch.
Das geht mit dem bekannten Einzeiler ja fix, indeed.

Wenn Du ein Recovery machen musst, weil ne Festplatte ausgefallen ist nützt Dir im ersten Schritt (wo Du womöglich keine Festplatte) ja kein Backup-Image, was irgendwie 3 Festplatten voraussetzt.
Exakt. Daher auch mein Gedanke, den pool zu erstellen und dann den aus dem Backup drüberschreiben. Fände es auch doof, jede Platte dann zu klonen.

Noch eine Zusatzfrage, die mir grad aufkam:
Wenn ich eine mit geli komplett verschlüsselte Platte ungemountet auf eine andere Platte 'raw' klone, wäre die Klonplatte lesbar oder meckert geli dann, dass es nicht das Original ist? Ich weiß nicht, ob das in den geli-Metadaten verewigt wird oder ob so ein Schutz überhaupt besteht.
 
#4
rclone kann Dateien mit diversen clouds, wie z.B. dropbox, Amazon S3, Google Drive, Own/Nextcloud und viele mehr, syncen. Ich nutze rclone und syncthing gelegentlich oder das gute alte rsync.
 

cla

IRC: Qyx
#5
Ein Voll-System-Backup (welches sowieso schon auf ZFS liegt) kann man doch schoen mit "zfs send/receive" in eine Image-Datei oder beliebigen anderen Ort (externe Disk; SSH-Remoteserver etc.) rueberschieben und davon auch wiederherstellen.

Zusaetzlich noch Dateibackups von den aktiven Daten (z.b. automatische Database-Dumps) mit beliebiger Backup-Software der Wahl.
 

medV2

Well-Known Member
#6
Wenn du ein Image willst spricht doch nichts gegen dd. Singlemodus mit Readonly hochfahren, oder einen LiveStick nehmen und go. Wenn du keine Verschlüsselung dazwischen hast, kannst du auch ein zstd oder ähnliches dazupipen.

Ich mache Systembackups seit jahren ganz unkompliziert mit tar. Möglichst alles stoppen was geht und nötig ist (eine Datenbank muss man beim Backup nicht stoppen, wenn man das müsste wäre es keine gute Datenbank). Danach einfach tar über das ganze System jagen - mit den excludes arbeiten für Sachen wie /proc /dev, ...
Wenn bei dir alles auf ZFS ist kannst du natürlich auch den zfs send stream in das tar packen.

Vor dem Restore muss man halt die Partitionen soweit wiederherstellen, dafür gehts dann auch schneller als ein dd zurück spielen.

Die einzelnen tars eines Systems kann man platzsparend dedupliziert speichern, z.b. mit zpaq.
 

Rosendoktor

Well-Known Member
#7
Wenn Du mit einem Livesystem bootest:

Du kannst einfach mit dd Images der Partitionen die Du sichern willst machen, z.B. auf eine angeschlossene externe Platte. Vorteil: Einfach. Nachteil: Du hast halt pro Version und Partition je eine Riesendatei die Du auch nur wieder auf eine identische Partition zurückkopieren kannst.

Du kannst mit rsync dateibasiert die Partitionsinhalte in unterschiedliche Ordner (auf der externen Platte) sichern. Mit rsync kannst Du auch die vorhandenen Backups updaten, also nur die Änderungen in bereits vorhandene Backup Ordner schreiben. Oder nur die Änderungen bezogen auf einen bereits vorhandenen Backupordner in einen neuen Ordner schreiben (rsync arbeitet dabei mit Hardlinks). Vorteil: Dateisystemunabhängig. Nachteil: Etwas komplizierter.

Du kannst wenn Du sowieso ZFS benutzt per send/receive ein Backup erstellen. Vorteil: Einfach. Nachteil: Dateisystemspezifisch.

Such's Dir aus...

Ich habe bisher die rsync Methode benutzt, unter FreeBSD und unter Linux. Nach dem gerade erfolgten Umstieg von UFS auf ZFS und von ext4 auf btrfs werde ich wohl mischen zwischen der rsync Methode und den spezifischen ZFS und btrfs Möglichkeiten.
 

foxit

Moderator
Mitarbeiter
#8
Ich wollte mal, um Denkanstöße zu bekommen, in die Runde fragen, wie ihr fertig konfigurierte Installationen wegsichert.
Überhaupt nicht! Natürlich sichere ich Daten, die auf dieser VM erstellt werden (MariaDB, SQLite ect.). Dafür habe ich BareOS in Gebrauch. Aber für den Rest? Früher hatte ich Subversion, welches mir ein Backup von "/etc" und "/usr/local/etc" verwaltete. Heute erstelle ich die VM einfach neu. Muss es nicht viel eher Ziel sein, den Zustand einer VM (oder was auch immer) automatisiert erstellen zu können? Ein klares JA von mir. Sollte der Server mal nicht mehr funktionieren, kann ich ihn einfach in wenigen Minuten wiederherstellen. Mir ist klar, dass dies gewisse Voraussetzungen bringt aber diese muss mal halt lösen. Zum testen verwenden ich aktuell z.B. Vagrant inkl. Ansible/Saltstack. Die VM wird erstellt und danach automatisch konfiguriert. Diese Konfiguration habe ich in einem Git Repo. Für Updates, verwende ich zusätzlich noch Snapshots. Entweder von ZFS oder vom Hypervisor direkt.
 

mr44er

Well-Known Member
Themenstarter #9
Vielen Dank für die Tips!

Ich denke, ich werde auch gemischt fahren. Einmal die configs mit rsync wohin und auf die externe Platte zfs-snapshots schieben. Ich fahre ZFS-only, habe es einfach liebgewonnen.
Da kann ich wie gewohnt geli auf die externe legen, zfs drüber und habe Kompression+Geschwindigkeit.

Ich werde die externe Platte auch nur fürs Backup nutzen. Damit sind mir die snapshots irgendwie lieber als tar-files. Obwohl das absolut unbegründet ist und keinen Unterschied darstellt.

Sollte der Server mal nicht mehr funktionieren, kann ich ihn einfach in wenigen Minuten wiederherstellen. Mir ist klar, dass dies gewisse Voraussetzungen bringt aber diese muss mal halt lösen.
Akut wäre es bei mir zuhause overdozed mit ner kleinen Serverfarm zu arbeiten, aber ich stimme dir generell zu.
Ich hab dunnemols mit VMware dieses Umschwenken bei physikalischem Ausfall (Name liegt mir auf der Zunge) ausprobiert. Ich wusste ja, was passieren wird, aber mir ist dennoch die Kinnlade runtergeklappt, als ich den Stecker zog und der ping weiter lief. Hat mich arg beeindruckt.
Dafür klappt bei anderen bei Feuerwerk die Luke runter. :rolleyes:
 

mr44er

Well-Known Member
Themenstarter #11
Gar nicht mal so doof, wenn ich die externe Platte als Mirror hinzufüge und danach als 'degraded' weiterfahre. Dann brauchts ja wirklich nur die Bootpartition. Yeah, piece of cake.:)