[TUTORIAL] Proxmox PVE-Host Backup and Desaster Recovery mit PBS

[floh8]

Hallo Leute,
Ich hatte es bereits mit den jüngeren Versionen von PBS probiert, aber nie Erfolg gehabt. Mit der aktuellen Version von PVE 7.0.8 und PBS 2.0.4 funktioniert es endlich.
Ziel: möglichst schnelles Restore eines ausgefallenen PVE-Hosts über den Proxmox Backup Server.

Voraussetzung: Normal ist die Benutzung von BTRFS und ZFS für die Spiegelung der Installation vom PVE sehr sinnvoll. Leider ist die Wiederherstellung nicht zwingend so konsistent wie eine Imagesicherung. Man muss auf jeden Fall eine frische PVE-Installation durchführen. Dies geht auch schnell, aber nehme ich eine neuere Proxmox-CD könnte das Plattendesign schon wieder etwas anders sein. [unten im weiteren Post die entsprechenden Hinweise] Schön ist es immer, wenn man für alle Backups das gleiche Zielsystem/Lösung nutzen kann, was bei einer File-based Sicherung auf einen PBS auch gegeben wäre. Siehe mein Post: Filebased Sicherung für ZFS,BTRFS mit PBS.

--> für Sicherung und Desaster Recovery des PVE-Hosts mit SW-RAID BTRFS oder ZFS über PBS findet ihr unten im weiteren Post die entsprechenden Hinweise

Wir wissen, dass der PBS erst zu 60% fertig ist und noch wachsen WIRD. Das ist nun mal der normale Lauf.
Meine Lösung hier setzt ein Blockdevice zur Installation voraus - sinnvoller Weise ein HW-Raid1. Da man hier keinen Bitrotate-Schutz hat, sollte man in Produktionsumgebungen Enterprise-Class-HDDs verwenden.
Beim Restore kann der Backup-Client leider noch nicht direkt auf das Blockdevice zurück sichern, deshalb gehen wir einen kleinen "Umweg". [bzw. siehe Ergänzungspost]
Leider habe ich diese Lösung nicht mit einem PVE-Host im Cluster probiert, da ich vermute, dass die Clusterkonfiguration dann nicht mehr mit den anderen Hosts harmoniert. Bei Windows wäre das auf jeden Fall so ;-). Man muss diese bestimmt manuell korrigieren, indem man den Host temporär aus dem Cluster entfernt und dann wieder integriert, könnte ich mir vorstellen. Es sei aber jeder ermutigt, dies mal nachzustellen und hier zu berichten.

Sicherung kann im Livebetrieb dann inkrementell passieren.

- # proxmox-backup-client backup pve_sda.img:/dev/sda --repository 192.168.122.3:bkpstorage --backup-type host --crypt-mode none

-> dies vollführt eine Image-Sicherung (nicht konsistent) vom Blockdevice sda auf den PBS
- das Blockdevice steht sinnbildlich für das HW-RAid und enthält dann alle Partition, LVM-Volumes, Bootmaster und Co

Wiederherstellen

0. man startet nun den PVE-Host von einer Live CD - am besten Debian - bei mir war es eine Version 10
[zusätzlich steckt man ein Laufwerk hinzu (zB USB), das größer ist als dein Boot-Blockdevice im Host]

1. Installieren des Backup-Clients
Debian 10:


# sudo apt install wget # sudo wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

- in source.list einfügen:

# sudo echo "deb http://download.proxmox.com/debian/pbs-client buster main" >> /etc/apt/sources.list

- dann
#sudo apt update und client installieren
# apt-get install proxmox-backup-client

2. Sicherung temporär zurückspielen (kleiner Umweg)

- die zusätzliche Platte formatieren und einhängen (bei mir unter /mnt)
- jetzt Restore der Sicherung in eine temporäre Datei (pve_root.img) auf dieser Zusatzplatte
# proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img /mnt/pve_root.img --repository 192.168.122.3:bkpstorage

3. nun temporäre Imagedatei auf Blockdevice übertragen

# dd if=/mnt/pve_root.img of=/dev/sda bs=4096

Fertig

- nach Reboot ist der alte Host wieder online

Vorteile dieser Lösung:

- ich kann im Livebetrieb regelmäßig sichern
- nur wenige Schritte zum kompletten Restore - keine Neuinstallation wie bei einer File-Restore Lösung
- man hat Boot Medium für Desaster Recovery
- PBS wird auch als Backupziel für die PVE-Hosts genutzt - keine separate Backupumgebung für Hosts notwendig (wie wenn ich z.B. synology nutzen würde)

 

[fpausp]

Hallo @floh8, mich würde deine Meinung über meine Lösung zu diesem Thema interessieren: Desaster Recovery ?

 

[floh8]

Ergänzung:
Man kann den Restore doch ohne "Umweg" also ohne Zusatzplatte tätigen, wenn man Linux besser kennt, was ich nicht tue. Proxmox hat nämlich dem Client genehmigt an stdout zu senden. Das erfolgt mit "-", wie in der Doku erwähnt. Der folgende Befehl würde also Punkt 2 und 3 von oben zusammenfassen.

# proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img - --repository 192.168.122.3:bkpstorage | dd of=/dev/sda bs=4096

 

[Dunuin]

Werde ich die Tage mal testen.

Was mir da vorschweben würde wäre ein USB Stick mit einem persistenten Live Debian 11 drauf. Den müsste ich dann nur einmal einrichten und könnte dann immer von dem booten um meine beiden Boot/Root-SSDs zu sichern bzw im Ernstfall dann auch wiederherzustellen. Da würde dann sicher auch ein Bash-Script Sinn machen, was dann nach dem Boot per Autostart mitgestartet wird und einen dann fragt ob man ein Backup sichern oder wiederherstellen will. Wenn man es richtig gut machen will könnte man auch noch eine Menüführung einbauen welche...
1.) einem vor dem Sichern fragt welche Laufwerke man sichern will. Hier könnte man dann eine Tabelle mit sdX, UUID, Modell und Größe angezeigt bekommen. Und das zuletzt gewählte könne man dann in einer Konfig-Datei per UUID speichern, damit sich das Script das zuletzt gewählte merken kann und man es nicht für jede Sicherung neu wählen muss.
2.) einem vor dem Restore eine Liste mit allen Backups anzeigt und dann ein entsprechendes Backup wählen lässt. Danach eine Liste mit allen verfügbaren Images des gewählen Backups. Dann wählt man das (einzelne) gewünschte Image und danach wählt man das Ziellaufwerk.
3.) es einem erlaubt den Server automatisch nach dem erfolgreichen Backup zu rebooten, damit man wieder in PVE landet

Das wäre dann wirklich super praktisch. Da würde ich den USB Stick dann einfach immer gesteckt lassen. Und steht dann mal wieder ein PVE update an, starte ich kurz im Browser das WebKVM vom IPMI, reboote den Server, Drücke F12 oder was das war um statt von den SSDs vom USB-Stick zu booten. Dann bin ich automatisch im Backup-Script, kann mit 2 Klicks kurz ein Sichern veranlassen und muss dann nur rebooten und bin wieder normal im PVE. Und dann kann ich normal mein PVE updaten ohne groß Sorgen haben zu müssen, dass da das Update etwas zerschießt.

Weil mein PVE ist schon etwas komplizierter und da steckt viel Arbeit (bestimmt 100+ Stunden) drin. Da kann ich nicht mal schnell ein neues PVE aufsetzen wenn etwas kaputt gehen sollte.


Aber bist du sicher, dass das mit dem Blocklevel Backup im laufenden Betrieb wirklich klappt? Normalerweise wird ja davon abgeraten z.B. ein fsck, Partitionierung etc auf einem Laufwerk durchzuführen, welches noch gemountet und in Benutzung ist. Und selbst auf Dateiebene möchte man ja normal nicht einfach im laufenden Betrieb ein Backup machen sondern vorher ein Snapshot erstellen und dann das Backup auf Basis des Snapshots erstellen.

 

[floh8]

Ergänzung zu SW-Raids:
ich betrachte hierbei mal nicht mdadm-Raids, weil die aus meiner Sicht nicht mehr Stand der Technik für System-Raids sind, und btrfs, weil wir noch nicht wissen, wie sich die Konfiguration bei Proxmox weiter entwickelt. Es ist ja nur experimentell gelabelt. Somit habe ich den Wink von @Dunuin mal aufgegriffen und mir nochmal Gedanken zum zfs als Rootfilesystem gemacht.
Man kann natürlich eine Offline-Sicherung beider Platten machen. Dies habe ich mal getestet und keine Probleme festgestellt. Somit kann ich eine Offline-Sicherung eines zfs-Systems sehr gut als Rollback verwenden, wenn ich Systemupdates fahre. Herunterfahren kann ich den Host ja ohne Probleme, da zu so einer Wartung keine aktiven Container oder VMs laufen.
Für die alltäglichen Konfigurationsänderungen reicht dies natürlich nicht aus, weil ich das System vor der Änderung herunterfahren muss. In meinem Thread zu zfs/btrfs stelle ich die Snapshot-Funktion als sehr nützlich raus. Nachteil ist trotzdem, ich muss das System für ein Rollback neu booten. Wenn ich ein DR-Fall habe, nützt mir nur ein aktuelles Offline-Backup, Snapshot alleine nützt nichts. D.h. im Endefffekt hat jede Sicherungsvariante, von der man hier im Forum liest, ihre Berechtigung.

Folgende Varianten sehe ich:

Backup-Typ​	Erstellen​	Nutzen​	Restore​
zfs snapshot	online	Systemupdate, Konfigurationsänderungen	offline, Live-CD
Voll-Image HDD1/2 auf PBS	offline	DR, Systemupdate	offline, Live-CD
Image Part1/2,MBR auf PBS	online	DR, Systemupdate	offline, Live-CD
Filebased auf PBS	online	DR, Konfigurationsänderung	online+offline

Für die optimale Installation eines PVE würde ich also Folgendes nutzen:

1. System mit zfs installieren

2. folgende Backupvarianten stehen zur Auswahl

Jeder muss halt selber entscheiden, was für ihn besser ist. Nochmal gegenüber gestellt.

Eigentschaften​	Variante 1​	Variante 2​
Sicherungen	1) zfs snapshot + 2) Image v. Part1/2,MBR(2x) + 3) Filebased	1) Voll-Image (2x) + 2) Filebased
Zeitaufwand Sicherung	viel geringer	normal
Zeitaufwand Rollback	viel geringer	normal
Sicherung online	ja, alle Sicherungen	nur Filebased
Rollback online	nein	nein
DR Tasks	1) Neuinstallation von ISO + 2) Restore Image Part1/2 (2x) + 3) Restore filebased	1) Restore Voll-Image v. hdd1/2 + 2) Restore Filebased
DR Zeitaufwand	gleich	gleich
Singel File Restore	ja	ja

Nüchtern betrachtet wäre Variante 1 viel effizienter, weil ich die Sicherungen alle online machen kann.
Den MBR benötige ich eigentlich nicht, weil ich für das DR sowieso von ISO installieren muss. Er muß theoretisch auch nur am Anfang einmal gesichert werden, weil er sich nie ändert. Mit meiner Filebased-Sicherung kann ich individuelle Restores einer Datei anschieben. Wenn ich mir also ein Verzeichnis /backup anlege und dort ein dd-image vom MBR reinlege, könnte ich dieses individuell über die filebased-Sicherung wiederherstellen. Für Partitionen 1 und 2 arbeitet der backup-client auch in Kombination. Man könnte also für eine Komplettsicherung auch verwenden:

# proxmox-backup-client backup pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 ......pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 pve_root.pxar:/ --repository 192.168.122.4:bkpdatastore2 --backup-type host --crypt-mode none

Kurzübersicht:​

Sicherung vor einem Systemupdate:

1. zfs snapshot

Sicherung nach einem Systemupdate (=Vollisicherung für DR):

[1. ] # dd if=/dev/sda of=/backup/mbr_sda.img bs=512 count=1 # dd if=/dev/sdb of=/backup/mbr_sdb.img bs=512 count=1

2. # proxmox-backup-client backup pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 pve_sdb1.img:/dev/sdb1 pve_sdb2.img:/dev/sdb2 pve_root.pxar:/ --repository 192.168.122.4:bkpdatastore2 --backup-type host --crypt-mode none

 

[floh8]

Da würde dann sicher auch ein Bash-Script Sinn machen, was dann nach dem Boot per Autostart mitgestartet wird und einen dann fragt ob man ein Backup sichern oder wiederherstellen will. Wenn man es richtig gut machen will könnte man auch noch eine Menüführung einbauen welche...

Das wäre natürlich eine klasse Sache so ein Script. Das könntest du dann an Proxmox verkaufen, damit es im PBS Debug-Modus nutzbar ist.

Weil mein PVE ist schon etwas komplizierter und da steckt viel Arbeit (bestimmt 100+ Stunden) drin. Da kann ich nicht mal schnell ein neues PVE aufsetzen wenn etwas kaputt gehen sollte.

Du beziehst dich sicherlich auf eine Plattenkonfig. Die könnte der proxmox-client halt online nicht mit sichern.

Aber bist du sicher, dass das mit dem Blocklevel Backup im laufenden Betrieb wirklich klappt?

Na, ich habs ja getestet. Gut meine Daten waren nicht kompliziert. Proxmox hat nichts anderes umgesetzt als andere Anbieter auch. Denke mal an Veeam. Da kannst du auch ein gemountetes System konsistent sichern oder das Project rear, dass sehr viele Provider einsetzen. Sehr beliebt. Das läuft auch online. Es sind keine konsistenten Backups. Ich fand einen Hinweis hier im Forumsportal, dass eine Sicherung im laufenden Betrieb vom proxmox-backup-client nicht konsistent ist. Für den Host ist es aus meiner Sicht nicht so schlimm, denn hier laufen keine DBs oder ähnliche Apss, die sowas benötigen. Ich habe es oben hinzugefügt. Wenn es doch Probleme geben sollte, könnte man die Dienste vorher anhalten.

 

[Dunuin]

Du beziehst dich sicherlich auf eine Plattenkonfig. Die könnte der proxmox-client halt online nicht mit sichern.

Ich habe da ziemlich viel am Host geändert...

• Ist ein Debian 10 mit PVE oben drauf und nicht einfach die PVE ISO
• ist Systemvollverschlüsselung
• initramfs-dropbear (angepasst für VLAN support + eigenem unlock Script) statt dem normalen initramfs damit ich root/swap per SSH Passworteingabe entschlüsseln kann
• SWAP, boot und root Partitionen als mdadm raid1 weil man von einem verschlüsselten ZFS nicht booten konnte (geht wohl seit OpenZFS 0.85 inzwischen)
• Zabbix Agent mit etlichen individualisierten templates und Scripts die z.B. über smartctl die Laufwerksdaten, ZFS Statistiken etc mitloggen
• Filebeat um meine Logs an Graylog zu senden
• eigenes Script was per ipmitool meine Hardware überwacht und die Lüfter regelt
• eigenes Script zum Entschlüsseln und Mounten meiner ZFS und LVMthin VM Storages sowie starten meiner VMs
• ziemlich aufwändige Netzwerk-Konfiguration mit 7 NICs, 13 VLANs, 14 Bridges, massig Firewall-Regeln, ...
• etliche nachinstallierte Programme zum Flashen von Firmwares etc, ZED, ipmitool, Skripte für automatische Snapshotverwaltung, ...
• Installation von Postfix als Email-Server
• Einrichtung von NUT für geregeltes Shutdown bei Stromausfall
• selbstgeschriebene systemd Scripts
• Anpassung von etlichen Konfigdateien wie ksmtuned, zfs, sysconf, sshd, crontab, fstab
• Einrichtung von etlichen PAM Usern/Gruppen, Einrichtung von sudo, Erstellen von neuen Rollen für PVE
• direktes einbinden verschiedenster SMB/NFS Shares über fstab
• Konfiguration von Backups
• verschiedenste Ordner wie /tmp auf RAM-Disks auslagern
• Einrichten von IOMMU-Support für NIC/GPU passthrough
• standby für HDDs über hdparm verbieten
• Anpassung des Intel_Pstate Governors für bessere Energieeffizienz
• ...

Das wäre schon super nervig wenn ich alles neu machen müsste...

Na, ich habs ja getestet. Gut meine Daten waren nicht kompliziert. Proxmox hat nichts anderes umgesetzt als andere Anbieter auch. Denke mal an Veeam. Da kannst du auch ein gemountetes System konsistent sichern oder das Project rear, dass sehr viele Provider einsetzen. Sehr beliebt. Das läuft auch online.

Also für mein Windows habe ich noch kein Backup-Tool gefunden was im laufenden Betrieb läuft und wirklich alles sichern kann ohne dabei früher oder später abzubrechen. Normalerweise arbeiten die Backup-Tools wie UrBackup etc ja so, dass diese Shadowcopy benutzten um quasi ein Snapshot vom NTFS anzulegen und basierend dadrauf machen die dann ihre Backups. Weil alle meine SSDs aber mit Veracrypt verschlüsselt sind kann Windows kein Shadowcopy mehr benutzen und das hat dann zur Folge, dass da kein Backup-Programm in der Lage ist irgendwelche Dateien zu sichern welche gerade geöffnet sind und benutzt werden. Gerade auf C sind dann immer irgendwelche Systemdateien die sich einfach nicht sichern lassen wollen. Das macht dann inkrementelle Backups nicht nutzbar, da ja nie wirklich alles gesichert werden kann und jedes Backup dann unvollständig ist. Das beste was ich da bisher gefunden habe ist einfach alles per rsync auf mein NAS zu schieben und weil es keine Versionierung gibt werden dann halt alle Backupversuche kombiniert und man erhält einen Brei aus Daten der relativ vollständig sein sollte, wovon aber alle Dateien unterschiedlich aktuell sind. Versionierung erhalte ich dann weil unten drunter ZFS mit Snapshots läuft. Aber ist halt schon ziemlich unschön das Ganze.

 

[floh8]

Wow, du stehst mal auf Sicherheit und Effizienz. Das is fett. Mein Respekt.
Ja, wenn man mit Verschlüsselung arbeitet, dann ist man beim Backupen schon ganz schön eingeschränkt - keine Frage. Diesbezüglich habe ich wenig Erfahrung. Mit 'ner individuellen Installation + Verschlüsselung ist die Offline-Variante wohl der simpelste Weg, denke ich.
Für deine Clients könnte dich ja https://www.askwoody.com/forums/topic/veracrypt-and-backup/ interessieren.

 

[Dunuin]

Wow, du stehst mal auf Sicherheit und Effizienz. Das is fett. Mein Respekt.
Ja, wenn man mit Verschlüsselung arbeitet, dann ist man beim Backupen schon ganz schön eingeschränkt - keine Frage. Diesbezüglich habe ich wenig Erfahrung. Mit 'ner individuellen Installation + Verschlüsselung ist die Offline-Variante wohl der simpelste Weg, denke ich.
Für deine Clients könnte dich ja https://www.askwoody.com/forums/topic/veracrypt-and-backup/ interessieren.

Ja, wenn dann auch richtig.
Am liebsten würde ich hier daheim ja einen HA Cluster mit CEPH aus 3 Nodes betreiben, aber das gibt leider das Budget und die Stromrechnung nicht mehr her um mir noch einen 4ten und 5ten Heimserver anzuschaffen

 

[Dunuin]

Ich habe mir jetzt einmal die ganze backup-client Dokumentation durchgelesen, aber eines ist mir immer noch unklar...
Wie sage ich dem backup-client unter welcher "group" die Backups gespeichert werden sollen?

Du gibst da nur "# proxmox-backup-client backup pve_sda.img:/dev/sda --repository 192.168.122.3:bkpstorage --backup-type host --crypt-mode none" beim erstellen an, wenn ich mir aber dein Restore Befehl angucke (proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img ...), dann landen die Backups unter der Gruppe "pve" auf dem PBS. Host gibt man mit "--backup-type host" an, aber in der Doku konnte ich weder einen Befehl finden, um die Gruppe manuell festzulegen, noch konnte ich entnehmen, woher der backup-client die Info dann beziehen sollte.

 

[floh8]

wenn du keinen paramter angibst, dann wird containerid oder vmid oder hostname genommen.
für individuelle manuelle aufrufe gibt es noch "--backup-id {bezeichnung}" als parameter.

 

[mr44er]

Ich werfe mal noch eine weitere Möglichkeit in den Raum ('mobiler' PBS als VM und vollverschlüsselt).

Man braucht dazu eine externe Platte und eine coldspare-Maschine, muss nichts aktuelles sein, nur UEFI sollte sie booten können. Wahrscheinlich ginge auch legacy, aber das hatte ich nicht probiert.

PBS ganz normal (ZFS raid0 / single disk) auf diese externe Platte installieren, dann von hier https://gist.github.com/yvesh/ae77a...malink_comment_id=4233326#gistcomment-4233326 die Schritte/Pfade auf PBS anpassen, also so:

zpool import -f -NR /tmp rpool && zpool status
zfs snapshot -r rpool/ROOT@copy
zfs send -R rpool/ROOT@copy | zfs receive rpool/copyroot
zfs destroy -r rpool/ROOT
zfs create -o encryption=on -o keyformat=passphrase rpool/ROOT
zfs send -R rpool/copyroot/pbs-1@copy | zfs receive -o encryption=on rpool/ROOT/pbs-1
zfs destroy -r rpool/copyroot
zfs set mountpoint=/ rpool/ROOT/pbs-1
zpool export rpool

*reboot*

Einmal den boot mit pw testen. Wenn alles ok ist, kann man die Gelegenheit gleich mal für updates nutzen.
Jetzt kann man die coldspare-Kiste runterfahren (nur noch für restore aus dem Schrank holen ) und die Platte abklemmen.

Nun richtet man sich eine neue VM ein (UEFI,Q35) und bindet die Platte raw ein. Es geht mit beiden Methoden, also entweder USB passthrough oder via ganzem Controller.
Es kann sein, dass die VM beim Booten hängt, aber das war in meinem Fall eine race condition, dass der passthrough nicht schnell genug passiert.
Ich habe das mit einem delay von fünf Sekunden gelöst:

nano /etc/kernel/cmdline
->
root=ZFS=rpool/ROOT/pbs-1 boot=zfs rootdelay=5

proxmox-boot-tool refresh
*reboot*

Nun noch kurz die Schnittstelle auf virtio ändern -> /etc/network/interfaces

Da wir das dataset rpool/ROOT nativ verschlüsselt haben, können wir im PBS sorgenfrei unser backup-datastore anlegen, da das auch darunter liegt.

Wenn jetzt das Desaster eintritt, bootet man die Platte einfach vom coldspare. Man muss dann nur noch je nach Hardware die Netzwerkschnittstelle wieder anpassen -> (vtnet/virtio auf der vom coldspare)

 

[mr44er]

Leider habe ich diese Lösung nicht mit einem PVE-Host im Cluster probiert, da ich vermute, dass die Clusterkonfiguration dann nicht mehr mit den anderen Hosts harmoniert. Bei Windows wäre das auf jeden Fall so ;-). Man muss diese bestimmt manuell korrigieren, indem man den Host temporär aus dem Cluster entfernt und dann wieder integriert, könnte ich mir vorstellen. Es sei aber jeder ermutigt, dies mal nachzustellen und hier zu berichten.

Ich habe den Test gewagt - und es funktioniert. Dazu sagen muss ich allerdings, dass ich ein konsistentes offline-Backup (zwei Wochen alt) wiederhergestellt habe, das online-Backup vom PBS hatte nicht funktioniert. Da hieß es dann, dass der rpool nicht mountbar sei, I/O-Fehler etc.
Zugute kam mir auch, dass ich genügend Nodes habe (neun Stück), kein rejoin zum Cluster war nötig und ceph hat sich die OSDs dann auch brav wieder recovered.
Man muss eigentlich nur drauf achten, dass die /etc/pve/corosync.conf identisch ist.

 

[bluesite]

Backup vom PVE Host Richtung PBS funktioniert das mach ich schon länger
Recovery hab ich noch nicht probiert gehabt

ich hab mir fürs Desaster Recovery nen PXE Image erstellt in dem alles drin ist was ich benötige
hab es jetzt mal probiert in einer VM
nach dem zurückspielen muss ich noch einen e2fschk machen mein PVE hat zur Zeit ext4
danach bootet er ohne Probleme (in der VM habe ich vorher noch die fixe IP geändert sonst ist die ja doppelt)

für die Zukunft werde ich auf dem zweiten PBS den ich habe noch Proxmox installieren das ich da dann im Notfall die VM mit PXE Server starten kann und die Pihole LXC da dort mein Dhcp Server läuft
Dann sollte das Recovery nur paar Minuten dauern und alles läuft dann wieder.
Meinen PVE sicher ich täglich auf den PBS dank Deduplierung und inkrementeles Backup braucht das ja kaum Speicherplatz

 

[michael.heider]

Hier mal ein Backup Prozedere als Bash script. Kommentar in English.

The basic idea is to backup the PVE host to PBS using this procedure:
1. snapshot the host's root filesystem using ZFS
2. use the Proxmox Backup Client to copy the contents of the snapshot to PBS
3. delete the snapshot

Snapshotting using ZFS is required, as the Proxmox Backup Client does not guarantee snapshot semantics.
Deleting the snapshot again is to save space.

The Proxmox Backup Client only transfers new/changed data, even if previous snapshots do not exist anymore locally.

We do not use `zfs send` directly as we want to leverage the PBS features instead of just manually collecting ZFS snapshots on another machine.

This procedure backs up the ZFS dataset `rpool/ROOT/pve-1`, which is most things. _Not backed up_ are: boot partition, ZFS pool setup, other ZFS datasets in `rpool/ROOT/` and elsewhere, guests. The boot partition and ZFS pool setup are relatively easy to recreate. Backup of guests is done separately.

#!/bin/bash
set -euo pipefail
# Make a backup of a PVE or PBS host.
# First, snapshot ZFS to guarantee consistency.

# PARAMETERS
# backup name: use the hostname
BACKUP_NAME='***TODO***'
# The dataset, needs to be a leaf.
# on PVE: `pve-1`, on PBS: `pbs-1`
ZFS_DATASET='***TODO***'
# PBS domain. On PVE: use URL (such that cert can be verified), # on PBS: use localhost
PBS_DOMAIN='***TODO***'
PBS_USER_PASSWORD='***TODO***'
# SCRIPT
now=$(date --utc +'%Y-%m-%dT%H:%M:%S')
snapshotName="snap_$now"
# create snapshot
echo "create snapshot $ZFS_DATASET@$snapshotName"
zfs snapshot "rpool/ROOT/$ZFS_DATASET@$snapshotName"
# backup to PBS
# requires root to read all the files in the snapshot
export PBS_PASSWORD="$PBS_USER_PASSWORD"
proxmox-backup-client backup "$BACKUP_NAME.pxar:/.zfs/snapshot/$snapshotName/" \
    --repository "pve-host-backup@pbs@$PBS_DOMAIN:pve-host" \
    --backup-type host \
    --crypt-mode none
# delete snapshot
echo "delete snapshot $ZFS_DATASET@$snapshotName"
zfs destroy "rpool/ROOT/$ZFS_DATASET@$snapshotName"

Schedule the script as cron job. In my case, twice a day.

Das Skript funktioniert auch, um nen PBS Host zu backupen. Wobei n PBS sich natürlic hauf sich selber backuped, was dann kein wirkliches Backup mehr ist. Es hilft aber trotzdem, ältere Versionen zu haben. Ausserdem könnt man die Backups aus der Web UI auch einfach herunterladen.

Wiederherstellung:
Das hab ich leider noch nicht probiert. Aber der Plan ist:

- live-boot PVE installer
- install PVE
- the version should not matter too much, but ideally, use the same or a similar one as in the backup
- required to get a basic running system (disk ashift, boot partitions, disk redundancy setup, etc.)
- boot into live medium again
- detach created ZFS dataset `rpool/ROOT/pve-1`
- restore from backup on PBS
- attach restored dataset as new `rpool/ROOT/pve-1`

 

[maxprox]

Hi Michael,

danke dir für dein Skriptbeispiel!
mein unwichtiger Tipp:
drei Jahre nach Themenstart, hättest du das besser als neuen Post [Tutorial] aufgemacht, dann würde dein Skript hier nicht so untergehen ;-)

Grüße,
maxprox

 

[Softwald]

Hi @michael.heider !

Schließe mich @maxprox an: Schade, dass das Script in einem alten Post gelandet ist.

Ich würde das Script gerne Testen und auch den Restore, es sei denn jemand hat schon Erfahrungen damit gemacht aber, einige Unklarheiten habe ich bei dem Script noch:

# PBS domain. On PVE: use URL (such that cert can be verified), # on PBS: use localhost
PBS_DOMAIN='***TODO***'
PBS_USER_PASSWORD='***TODO***'

Was ist hier mit "On PVE: use URL" gemeint?
Was ist die "PBS_DOMAIN"?

Vielleicht steh ich hier auch einfach auf dem Schlauch und die Antworten sind offensichtlich.

 

[michael.heider]

Hi @Softwald

Ist toll, dass das Skript Leuten hilft.

Die PBS_DOMAIN ist die Domain vom Proxmox Backup Server. Also z.B. pbs.example.net, oder was das bei dir halt ist. Wenn Du das Skript auf dem PVE verwendest, gibst du pbs.example.net an, auf dem PBS (um den PBS selbst zu backupen) aber localhost. Mit ner IP direkt würds theoretisch auch gehen, dann müsstest dus aber noch so konfigurieren, dass das Domain Zertifikat (was ja dann falsch ist) nicht geprüft wird.