[TUTORIAL] PBS-Host Backup for daily Change Rollback

[floh8]

Dies ist ein Empfehlung, wie man den PBS absichert, wenn man sich vor Fehlverhalten des Systems nach Änderungen jeglicher Art wie Updates, Konfigurationsänderungen, etc. absichern möchte, um auf den alten Versionsstand zurückkehren zu können. Diese Hinweise beziehen sich nicht auf ein DR-Szenario, wenn ich z.B. nicht mehr Booten kann oder die Hütte abgebrannt ist. Dazu lest bitte hier: DR PBS.

Den PBS für eine PVE-Umgebung kann man ja auf verschiedene Weise Implementieren. Ich bevorzuge meine Stage 1 - Sicherung (Platte) möglichst extrem ausfallsicher zu gestalten. D.h. man sichert sich auch gegen HW-Ausfall des PBS-Hosts ab. Dafür gibt es nach meinem Wissenstand 2 kostengünstige Möglichkeiten.

1. Man setzt eine Dual-Head-Serverlösung ein

• dies ist eine Virtualisierungslösung in klein, aber der PBS ist separat vom Haupt-Virtualsierungscluster
• entweder mit Single JBOD oder komplett redundant
• Vorteil dieser Lösung:

- ich kann Band-Library nutzen, wo das Laufwerk 2 Data-Ports hat​

- ich spare ein Satz Platten, wenn ich Single JBOD nutze​

​

2. Man Installiert den PBS als VM in Haupt-Virtualsierungscluster, der einen 2. StorageCluster anspricht

• man baut einen StorageCluster mit 2 Nodes aus Commodity-Hardware mit einer kostenlosen Storagelösung wie GLusterFS/DRBD
• Datastore lege ich direkt auf NFS
• um split-brain zu vermeiden, konfiguriere ich Arbiter gleich in der PBS-VM oder extra HW
• den PBS sollte ich als VM installieren, damit ich Snapshot habe
• ACHTUNG: Hier sind 3 Hosts zu sichern. 2x StorageNodes + PBS-VM/Arbiter
• Nachteile d. Lösung:

- die Sicherungsdaten der VMs & Co laufen zu 2/3 zusätzlich von PVE-Host zu PVE-Host bei einem 3-Node-Cluster PVE​

- ich kann kein SAS-TAPE-LW nutzen​

• Vorteil d. Lösung:

- meine Backupdaten sind redundant vorhanden​

​

Welche Funktionen sollte meine Sicherung nun mitbringen, um daily-Rollbacks zu ermöglich?

- inkrementell oder differentielle möglich, wäre schön
- simple Retention Policy
- Benachrichtigung
- Single file Restore, wenn möglich
- Sicherung über Netzwerk
- bei VM-Lösung: Image-DesasterRecovery für StorageCluster
- wichtige Verzeichnisse: /boot/,/etc,/home,/root,/usr,/var

Wo sollte ich meine Backups sichern?

- sinnvoller Weise nutze ich meinen Hauptstorage, gleich am Standort
- alternativ irgendein günstigen selfhealing storage wie synology, truenas, omv

Welche Tools sind zu empfehlen?

1. für Dual-Head

• für virtuellen PBS nutze ich die Backuplösung v. meiner Virtualsierungslösung (z.B. vzdump)
• Ziel wäre der Hauptstorage
• für die PVE-Hosts ist rear +snapshot (zfs) zu empfehlen, um zusätzlich eine image-basierte DR-Lösung und snapshot v. root zu haben
• zusätzlich habe ich Snapshot-Funktion für PBS

2. für VM-Lösung

• nutze ich für die VM auch die integrierte Backupmöglichkeit von PVE
• leider fehlt der Single File Restore, aber das einfache Handling macht dies wieder wett
• zusätzlich habe ich die Snapshot-Funktion, die mir hilft, falls Fehler relativ zeitnah zur Änderung auftreten
• für die StorageNodes ist rear+snapshot (zfs, btrfs) zu empfehlen, um zusätzlich eine image-basierte DR-Lösung und snapshot v. root zu haben

Wie man dann im Detail für das 2. Storageziel am Standort A verfährt, hängt natürlich von der Konfiguration des PVE-Clusters und Hauptstorage und des genutzten Backuptool ab. Sinnvoll wäre es auf jeden Fall, nicht so viele verschiedene Lösungen zu bauen.

 

[floh8]

Ergänzungsgedanken zum Post:
Vielleicht fragt sich der eine oder andere, warum ich denn das ausfallsicher benötige. Darüber läßt sich wahrlich streiten, denn wie wahrscheinlich ist es, dass bei einem Ausfall des Backupsystems auch gleich mein Hauptsystem aussteigt? Nun ja, dies ist wahrlich nicht hoch, aber vielleicht möchte ja jemand eine bestimmte Dateiversion am Folgetag zurückgesichert haben. Da sieht es gleich ganz anders aus, da dies viel häufiger vorkommt. Wie lange dauert die Reparatur, ist wichtig? Hier kann man natürlich Vorsorge betreiben, indem man alle Ersatzteile lagernd hat.

Ich habe mal einen Test gemacht, ob eine HA-Lösung für den PBS überhaupt Sinn macht, wenn der Backupjob vom PVE unterbrochen wird. Es macht Sinn. Wenn ich ein Netzwerkproblem habe, aber mein PBS intakt ist, dann wartet wahrlich der Backupjob bis der PBS wieder verfügbar ist und macht dann weiter. Da lobe ich Proxmox schon mal. Was passiert aber, wenn meine PBS-VM während des Backupjob auf einem anderen Host neugestartet wird? Nur der aktuell unterbrochen Teil meines Backups also z.B. die spezielle VM bricht mit einem HTTP-Error ab, aber alle weiteren VMs werden wieder gesichert. Das ist natürlich großartig.

Wie könnte denn nun im Detail so eine Dual-Head-Lösung aussehn. Nun, da wird es schwierig, vor allem, wenn ich mit einem Single-JBOD arbeiten will, um Plattenkosten zu sparen. Also, mir sind einige Lösungen eingefallen, die alle unterschiedlich schwierig sind und natürlich ihre Nachteile haben. Eine Lösung, die ich gefunden habe und somit nicht von mir ist, dafür aber sehr interessant, will ich mal hier verlinken.
https://github.com/ewwhite/zfs-ha/wiki
Diese ist natürlich zu adaptieren auf die Proxmox-Produkte.

Wer eine ausfallsichere PBS-Lösung bereits gebaut hat, kann ja mal hier seine Lösung posten und schildern, welche Probleme er zu meistern hatte.

 

[floh8]

So, ich habe den Spass von oben adaptiert und zu meiner Überraschung, es funktioniert. Ich habe corosync und pacemaker konfiguriert und die S... funktioniert. Ich find's gut.
Also meine Testumgebung waren 2 PVE -Hosts und ein gemeinsames Blockdevice mit zfs. Das stonith-Device habe ich deaktiviert mit: crm_attribute --type crm_config --name stonith-enabled --update=false

Die resource-konfig habe ich mit importargs="-f -d /dev/" abgeändert.

Ich habe aber nicht die Clusterkonfig von Proxmox genutzt, aber ich bin mir sicher, dass es damit auch funktioniert.
Hinweis: Die Anleitung oben enthält lauter alte Befehle, da muss man etwas mitdenken. Die Fehlermeldungen sagen einem aber, was heutzutage richtig ist.
Für Proxmox ist so eine Lösung natürlich immer großartig, weil sie nun mehr Produkte verkaufen können. Gerngeschehen, aber nicht für dich Tom