Backup Einführung
Proxmox Heimserver Backup
1 - Backup Einführung
Sie kennen doch die drei Sätze die Sie nie, aber niemals, von euren System Administrator oder Consulting hören möchten.
- Das Habe ich noch nie gesehen!
- Oh! Das ist aber lustig
- Sie haben doch ein Backup, oder?
Natürlich müssen wir sicherstellen dass wir unseren neu aufgesetzten System sichern, den obwohl Proxmox sehr zuverlässig läuft ein Problem kann immer auftreten. Und das Backup nicht einfach ausschalten nach ein Paar Monaten, weil Sie noch nie ein Problem hatten, den genau dann wird Murphy’s Gesetzt eintreten, Sie wissen doch, dieses Geseztz das besagt dass es keinen Grund gibt warum das Schlimmste nicht passieren sollte.
Den ein guter Backup ist ein Backup den man nie braucht! Wenn man den aber braucht sollten die Daten nicht ein paar Tage oder sogar Wochen alt sein.
Das bedeutet wir brauchen ein Disk oder Speicherplatz außerhalb unseren Proxmox Server, am besten in einen separaten Raum, ich benutze mein alten NAS hierfür der liegt im Netzwerkschrank im Keller. Sie können aber auch ein USB Disk benutzen, Haupsache getrennt von den eigentlich Proxmox Server und groß genug um alle Daten zu sichern.
Weiterhin haben wir drei Sorten von Backup, einmal den Backup der Virtuellen Maschinen oder Container, das Backup der eigentlich Proxmox Konfiguration, und dann das Backup der Daten auf unseren ZFS pool.
Wir werden jetzt das Backup für
- die Proxmox Konfiguration
- für die VM oder Container
- für unseren ZFS Pool
- und die automatische snapshot für den ZFS pool aktivieren
Dafür wechseln wir in unseren Terminal session
2 - Backup der Vm oder Container
2.1 - NFS Anschluß
Falls Sie, wie ich, einen NAS Server benutzen wollen müssen diesen in den NAS als NFS share konfigurieren. Dann können Sie dieses share in Ihren Proxmox Server einbinden.
In den Terminal geben Sie die folgenden Befehle.
echo „backup:/data/Backup /backup nfs rw“ >> /etc/fstab
mkdir /backup
mount -a
mkdir -p /backup/pvetest/{config,dump,borgbackup}
Damit haben wir unseren share für das Backup vorkonfiguriert.
Falls Sie einen USB Disk benutzen, können Sie den letzten Schritt vergessen, schliessen Sie Ihr Disk an und überprüfen Sie ob das System den Disk gemountet hat. In den Terminal:
dmesg
[1034408.992911] scsi host28: usb-storage 2-5:1.0
[1034410.019036] scsi 28:0:0:0: Direct-Access WD My Passport 0820 1012 PQ: 0 ANSI: 6
[1034410.019219] scsi 28:0:0:1: Enclosure WD SES Device 1012 PQ: 0 ANSI: 6
[1034410.020505] sd 28:0:0:0: Attached scsi generic sg10 type 0
[1034410.020609] ses 28:0:0:1: Attached Enclosure device
[1034410.020671] ses 28:0:0:1: Attached scsi generic sg11 type 13
[1034410.021649] sd 28:0:0:0: [sdk] Spinning up disk…
[1034416.080627] ses 28:0:0:1: Wrong diagnostic page; asked for 1 got 8
[1034416.080632] ses 28:0:0:1: Failed to get diagnostic page 0x1
[1034416.080635] ses 28:0:0:1: Failed to bind enclosure -19
[1034417.090624] .ready
[1034417.091202] sd 28:0:0:0: [sdk] 3906963456 512-byte logical blocks: (2.00 TB/1.82 TiB)
[1034417.091508] sd 28:0:0:0: [sdk] Write Protect is off
[1034417.091509] sd 28:0:0:0: [sdk] Mode Sense: 47 00 10 08
[1034417.091800] sd 28:0:0:0: [sdk] No Caching mode page found
[1034417.091803] sd 28:0:0:0: [sdk] Assuming drive cache: write through
[1034417.180210] sdk: sdk1 sdk2
[1034417.181195] sd 28:0:0:0: [sdk] Attached SCSI disk
Wie Sie hier sehen ist unseren Disk unter /dev/sdk angehängt worden
Jetzt nur noch ein Verzeichnis erzeugen und den Disk mounten.
mkdir /backup
root@pve2:~# mount /dev/sdk2 /backup
root@pve2:~# df -h | grep usbdisk
/dev/sdk2 1.9T 404G 1.5T 22% /backup
mkdir -p /backup/pvetest/{config,dump,borgbackup}
Jetzt zu der Web Oberfläche:
Wir wollen unseren Backup als Storage hinterlegen. Wir klicken auf Datacenter und dann auf der rechter Seite auf Storage – Hinzufügen und Verzeichnis auswählen (/backup/pvetest/dump).
Inhalt als VZDump backup file
Knoten können Sie leer lassen oder Ihren Server auswählen und natürlich Aktivieren anklicken.
und dann hinzufügen.
Nach kurzer Zeit steht Ihr Backup Storage zur Verfügung.
Jetzt gehen wir direkt unter Storage auf Backup
Und wählen Hinzufügen
Ich empfehle immer zwei arten von Backup einmal in der Woche sollte alles gesichert werden, und jeden Tag die wirklich wichtigen Servern.
Das wäre erledigt, ab jetzt haben wir ein wochentliches Backup aller VM und Container.
Jetzt müssen wir nur noch ein tägliches Backup der wichtigen Server aufsetzen.
Jetzt nochmals auf Erstellen klicken
Und dann jeden anderen Tag nur die VM oder Container die für Sie wichtig sind.
Hier habe ich nur einen der beiden Server gewählt.
Dann nur noch die Informationen über der Anzahl der Backup die behalten werden müssen
Hier z.B. 4 Tage plus einen wöchentlichen Backup
2.2 - Backup der Proxmox Konfiguration
Warum sich anstrengend wenn es bereits ein kleines Program dafür existiert, vielen Dank hierbei an
# Author DerDanilo
# Contributors aboutte, xmirakulix, bootsie123, phidauex
Für dieses kleines Skript.
Sie können Sie es unter https://github.com/marcosgus/proxmox/blob/master/prox_config_backup.sh
finden, einfach alles mit der Maus markieren, kopieren zum Terminal wechseln und folgendes eingeben
mkdir -p /root/bin
cd /root/bin
vi /root/bin/pve_config_backup.sh
mit „esc“, „:i“ in den Editiermodus wechseln, die kopierten Zeile vom Github einfügen und anschließend in die Datei am Anfang den DEFAULT_BACK_DIR anpassen und das Verzeichnis der Backup Storage angeben, also in unsere Konfiguration, zum Beispiel /backup/pvetest/config.
Noch ein Wort über das Konfigurationsverzeichnis, /etc/pve ist ein virtuelles Filesystem das sich eigentlich in eine sqllite3 Datenbank ‚/var/lib/pve-cluster/config.db‘ befindet, eigentlich, den besten Weg diese konfiguration zu sichern wäre das sqlite3 backuptool zu benutzen es bedeutet auch Sie können die Konfiguration sichern ohne Proxmox anzuhalten. Deshalb müssen wir noch dieses Skript anpassen
Zwischen Zeilen 68 und 69 fügen Sie folgendes ein, einfach „esc“ eintippen und dann „:set nu“, damit schalten den Zeilenzähler ein, am Anfang der Zeile 69 gehen und mit „esc“ „:i“ in den Editor Modus gehen. Fügen Sie folgendes ein:
_filename9=“$_tdir/proxmoxconfigDB.$_now.db“
Dann in Zeile 135 folgendes:
sqlite3 /var/lib/pve-cluster/config.db „.backup ${_filename9}“
das Ganze speichern mit „esc“ „:wq“.
Jetzt müssen wir nur noch das Skript ausfühbar machen und in die crontab hinzufügen.
Am Terminal folgendes angeben
chmod 750 /root/bin/pve_config_backup.sh
crontab -e
Falls sie hier um Ihren beliebtesten Editor gefragt werden, geben Sie das was Sie haben wollen, ich nehme „vi“ (oder vim)
„esc“ „:i“ und dann folgende Zeile eintippen
45 23 * * * /root/bin/pve_config_bckp.sh > /var/log/pve/bckp.log 2>&1
„esc“ „:wq“
Die Zeile oben bedeutet nichts anderes als führe das Program /root/bin/pve_config_backup.sh aus um 23:45 Uhr jeden Tag und schreibe alle Antwort in die Datei /var/log/pve/bckp.log und wenn irgendetwas schief läuft schreibe es auch in die gleiche Datei (2>&1)
Ich würde regelmäßig das Ergebnis dieses Backup überprüfen, einfach mit cat /var/log/pve/bckp.log, da können Sie sehen was der Server protokolliert hat.
Aber jetzt lassen wir einfach das Skript laufen und schauen wir uns das Ergebnis an.
Direkt dafür kopieren Sie einfach die Zeile aus der crontab und kopieren Sie es in die Bash
crontab -l
45 23 * * * /root/bin/pve_config_bckp.sh > /var/log/pve/bckp.log 2>&1
Die Zeile nach dem letzten Stern bis zur ende der Zeile markieren und kopieren und in die Bash einfügen, und noch einmal leertaste drücken und „&“ eingeben plus die return Taste.
Das Program wird gestartet und in den Hintergrund geschickt, Sie können es überwachen in dem Sie einfach folgendes eingeben:
/root/bin/pve_config_bckp.sh > /var/log/pve/bckp.log 2>&1 &
tail -300f /var/log/pve/bckp.log
Am Ende haben Sie eine neue Datei in Ihren backup Verzeichnis
/backup/pvetest/config/proxmox_backup_pve2.netwitch.de_2022-12-04.23.45.01.tar.gz
Tar files
/etc/./
/etc/./.pwd.lock
/etc/./adduser.conf
/etc/./aliases
/etc/./alternatives/
/etc/./alternatives/README
/etc/./alternatives/arptables
/etc/./alternatives/arptables-restore
/etc/./alternatives/arptables-save
/etc/./alternatives/awk
/etc/./alternatives/awk.1.gz
/etc/./alternatives/ebtables
/etc/./alternatives/ebtables-restore
/etc/./alternatives/ebtables-save
/etc/./alternatives/editor
Das Programm erstellt zuerst eine Sicherung der Wichtigsten Verzeichnisse und dann ein detaillierte konfiguration und hardware Liste der Server.
2.3 - Backup der ZFS Pool VDEV’s mit BorgBackup
Natürlich haben wir bis jetzt nur die Daten der Proxmox Umgebung gesichert. Die Daten die auf dem Server sonst liegen wie z.B. Filme, fotos, Archive oder irgendein anderes Dateien Verzeichnis die innerhalb unseren Proxmox ZFS Disk sind nicht bei der Backup dabei. Diese müssen noch separat gesichert werden. Nun jetzt kommt das erstes Problem diese Daten nehmen viel Platz, zumindest bei mir, bei habe ich für die folgende Bereiche einen definierten zfs vdev.
data/dvr
data/backup
data/bilder
data/musik
data/timemachine
data/serien
data/videos
data/videos-private
data/vm
data/youtube
Diese Verzeichnisse sind bei mir sowohl als NFS als auch als samba share eingerichtet, Ich werde in einen späteren video erklären warum ich mich dazu entschieden habe an Stelle einer NAS Lösung (wie Freenas z.B.)
Nun all diese Verzeichnisse sind allesamt ca. 6,3 TB groß, also wenn man diesen auch sichern will muss man mindestens die gleiche Kapazität für den Backup vorhalten. Ich benutze dazu borgbackup dieses Backup tool ermöglicht einen deduplizierung und Komprimierung der Daten, was eine Unmenge an Platz spart. Hier z.B. den benutzte Kapazität bei mir
Original size | Compressed size | Deduplicated size
All archives: 6.32 TB | 6.08 TB | 3.21 TB
Wie Sie sehen können ist der Komprimierten Bereich nicht so gut, das kommt einfach von den Dateien typ die ich hier sichere (alles zusammen 3,2 TB an Filme, Musik oder Fotos. All diese Dateifomat sind bereits sehr stark komprimiert und da ist nicht mehr viel heraus zu holen. Aber bei der Deduplizierung da spare ich fast die Hälte der tastsälichen Platz.
Zuerst muss das borgbackup Programm installiert werden und dann verwende ich einen kleinen Skript den wir noch erstellen müssen.
apt install -y python3-pip borgbackup
python3 -m pip install pip –upgrade
Jetzt unseren Backup Verzeichnis initialisieren
root@pve:~/bin# borg init -e repokey-blake2 /backup/pvetest/borgbackup
Enter new passphrase:
Enter same passphrase again:
Do you want your passphrase to be displayed for verification? [yN]: N
By default repositories initialized with this version will produce security errors if written to with an older version (up to and including Borg 1.0.8).
If you want to use these older versions, you can disable the check by running:
borg upgrade –disable-tam /backup/pvetest/borgbackup
See https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-0-9-manifest-spoofing-vulnerability for details about the security implications.
IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
Use „borg key export“ to export the key, optionally in printable format.
Write down the passphrase. Store both at safe place(s).
Sie werden nach ein Passwort gefragt für die Verschlüsselung der Daten auf das Backup Medium.
Befolgen Sie hier einfach den Anweisungen. Und vor allem sichern Sie dieses Passwort und den Schlüssel sorgfältig, den ohne dem ist Ihr Backup Nutzlos, wenn Sie keine Verschlüsselung wünschen geben Sie
borg init -e none /backup/pvetest/test/
Hier haben Sie noch einen Überblick über die verschiedene Passwort-/Verschlüsselungs-modi
| Verschlüsselungsmodi | Beschreibung |
|---|---|
|
repokey and keyfile |
use AES-CTR-256 for encryption and HMAC-SHA256 for
authentication in an encrypt-then-MAC (EtM) construction. The chunk ID hash
is HMAC-SHA256 as well (with a separate key).
These modes are compatible with Borg 1.0.x. |
|
repokey-blake2 and keyfile-blake2 |
are also authenticated encryption modes,
but use BLAKE2b-256 instead of HMAC-SHA256 for authentication. The chunk ID
hash is a keyed BLAKE2b-256 hash.
These modes are new and not compatible with Borg 1.0.x. |
|
authenticated |
mode uses no encryption, but authenticates repository contents
through the same HMAC-SHA256 hash as the repokey and keyfile modes (it uses it
as the chunk ID hash). The key is stored like repokey.
This mode is new and not compatible with Borg 1.0.x. |
|
authenticated-blake2 |
is like authenticated, but uses the keyed BLAKE2b-256 hash
from the other blake2 modes.
This mode is new and not compatible with Borg 1.0.x. |
|
none |
mode uses no encryption and no authentication. It uses SHA256 as chunk
ID hash. This mode is not recommended, you should rather consider using an authenticated
or authenticated/encrypted mode. This mode has possible denial-of-service issues
when running borg create on contents controlled by an attacker.
Use it’s only for new repositories where no encryption is wanted and when compatibility
with 1.0.x is important. If compatibility with 1.0.x is not important, use
authenticated-blake2 or authenticated instead. |
Wenn Sie Ihre Daten irgendwo ins Netz stellen wollen, einen Passwortschutz und Verschlüsselung ist unumgänglich.
Nur noch unseren Backup Skript
#!/bin/bash
##################################
### Beispieldaten:
### logDirectory=“/var/log/pve/“
### backupDiscMount=“/backup/pvetest/borgbackup/“
### borgBackupDirs=“ Liste der Verzeichnisse die Sie sichern wollen“
##################################
export BORG_PASSPHRASE=’MyS3cr3tP@ssWort‘
export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes
export BORG_RELOCATED_REPO_ACCESS_IS_OK=yes
startTime=$(date +%s)
currentDate=$(date –date @“$startTime“ +“%Y%m%d_%H%M%S“)
currentDateReadable=$(date –date @“$startTime“ +“%d.%m.%Y – %H:%M:%S“)
logDirectory=“/var/log/pve“
logFile=“${logDirectory}/${currentDate}.log“
backupDiscMount=“/backup/pvetest/borgbackup“
borgRepository=“${backupDiscMount}“
borgBackupDirs=“/root /data/bilder /data/videos“
if [ ! -d „${logDirectory}“ ]
then
mkdir -p „${logDirectory}“
fi
errorecho() { cat <<< „$@“ 1>&2; }
exec > >(tee -i „${logFile}“)
exec 2>&1
if [ „$(id -u)“ != „0“ ]
then
errorecho „ERROR: This script must be run as root!“
exit 1
fi
echo -e „\n###### Start des Backups: ${currentDateReadable} ######\n“
echo -e „Daten werden zusammengestellt“
echo -e „\nBackup mit borgbackup“
borg create –stats $borgRepository::“${currentDate}“ $borgBackupDirs
echo
borg prune –progress –stats $borgRepository –keep-within=7d –keep-weekly=2
borg compact $borgRepository
endTime=$(date +%s)
endDateReadable=$(date –date @“$endTime“ +“%d.%m.%Y – %H:%M:%S“)
duration=$((endTime-startTime))
durationSec=$((duration % 60))
durationMin=$(((duration / 60) % 60))
durationHour=$((duration / 3600))
durationReadable=$(printf „%02d Stunden %02d Minuten %02d Sekunden“ $durationHour $durationMin $durationSec)
echo -e „\n###### Ende des Backups: ${endDateReadable} (${durationReadable}) ######\n“
echo -e „Plattenbelegung:\n“
df -h ${backupDiscMount}
Jetzt nur noch die nötigen Verzeichnisse anlegen und den Eintrag in die crontab hinzufügen, damit unseren Skript regelmäßig läuft
mkdir -p /var/log/pve /backup/pvetest/borgbackup
echo „15 0 * * * /root/bin/backup.sh > /var/log/pve/backup_data.log 2>&1“ >> /var/spool/cron/crontabs/root
Anschließend crontab aufrufen und einfach speichern
crontab -e
esc :wq
crontab -l
Zur Überpfrüfung
Natürlich müssen Sie hier die Verzeichnisse an Ihre Umgebung anpassen
2.4 - ZFS automatisierte snapshot
Eines der Vorteile von ZFS ist seine snapshot Möglichkeiten. Snapshot bei ZFS nimmt fast keine Kapazität in Anspruch. Es bedeutet Sie können sich erlauben für wichtige vdev eine Protokolierung der Änderungen in Ihre Dateien zu verfolgen, und im Fall eine unglückliche Fehler ( Datei gelöscht, oder fälschlicherweise überschrieben, etc…) diese Datei von Snapshot wieder her zu stellen.
Wir brauchen es nicht Manuell machen wieder gab es einige Leute die so etwas bereit entwickelten, wir können es also benutzen. Wir müssen zuerst das Program herunterladen und installieren und auf unseren Server brauchen wir einige zusatz Module
Login as root
apt install -y make gcc
dann
wget https://github.com/zfsonlinux/zfs-auto-snapshot/archive/upstream/1.2.4.tar.gz
tar -xzf 1.2.4.tar.gz
cd zfs-auto-snapshot-upstream-1.2.4
make installDas programm steht jetzt zur Verfügung wir müssen nur noch unseren vdevs unter ZFS konfigurieren
Ohne irgendwelche Konfiguration erstellt das Programm einen snapshot alle 15 mins für alle vdevs nach so genannten frequent snapshot und dann geht es weiter
4 frequents ==> hourly
24 Hourly ==> daily
8 daily ==> weekly
31 daily ==> monthly
12 monthly
Ich wurde empfehlen für das ZFS pool diesen snapshot zu deaktivieren, dafür dann für jede einzelne vdevs darunter zu überlegen ob diese snapshot gebraucht werden oder nicht. Hier z.B. eine Konfiguration für data/vm
zfs set com.sun:auto-snapshot=false data
zfs set com.sun:auto-snapshot=false data/vm
zfs set com.sun:auto-snapshot:monthly=true data/videos
zfs set com.sun:auto-snapshot:weekly=true,keep=8 data/videos
zfs set com.sun:auto-snapshot:daily=true data/videos
zfs set com.sun:auto-snapshot:hourly=true data/videos
zfs set com.sun:auto-snapshot:frequent=true data/videos
Nach ein paar Stunden können sie es kontrollieren mit
zfs list -t snapshot
Bis jetzt haben wir unseren Server und die Virtuellen Maschinen gesichert, wir müssen jetzt überprüfen ob diese Sicherung auch brauchbar ist.
3 - Wiederherstellung nach totaler Verlust (Disaster recovery)
3.1 - Proxmox Server wiederherstellen
Wir haben jetzt vier verschiedene backups
-
VM und Container backup.sh
-
Konfiguration’s backup
-
Borgbackup unserer ZFS Pool
-
zfs snapshot
Jetzt hängt die wederherstellung stark vom Problem den wir haben
-
Kompletter Verlust der Server (Brand, Kanne Kaffee, Fußball (nicht lachen mir ist es schon mal passiert), Gewitter mit unmittelbarem Blitzeinschlag, etc… ==> Hier werden wir Backup 2, 1 und 3 brauchen
-
Virtual Maschine stürzt ab oder startet nicht mehr nach einen unglücklichen update ==> Backup 1
-
Dateien versehentlich gelöscht ==> Backup 1 oder 4 oder eine Mischung aus Backup 1 und 4
Erster Schritt wird erstmal zu überprüfen ob die Hardware weiterhin wieder verwendet werden kann, notfalls zerstörte Teile durch neuer Komponente austauschen oder komplett neu aufbauen.
Nächste Schritte:
3.2 - Wiederherstellung nach totaler Verlust
-
Proxmox neu installieren
-
Kontrollieren Sie ob die Disk der ZFS Pool erkannt wurden und angezeigt werden (Webfrontend öffnen und anmelden)
-
Nach dem reboot der Server müssen wir die Dienste anhalten
for i in pve-cluster pvedaemon vz qemu-server; do systemctl stop $i ; done
-
Falls die Disks nicht von der Hardware Probleme betroffen waren Sollten Sie noch in der Lage sein die Daten wieder her zu stellen. Hier zwei Möglichkeiten
-
ZFS Pool wurde beim Booten erkannt und automatisch eingehängt ==> Kein Eingreifen nötig
-
ZFS nicht vorhanden ==> Hier Können Sie probieren den Pool zu importieren
-
Zuerst mit :
zpool status -v
no pools available
ZFS Pool wurde nicht erkannt, hier können Sie noch probieren diesen Manuell zu importieren
zpool import
pool: data
id: 14024415627059556521
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
data ONLINE
raidz1-0 ONLINE
scsi-0QEMU_QEMU_HARDDISK_drive-scsi4 ONLINE
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3 ONLINE
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 ONLINE
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 ONLINE
Jetzt nur noch zpool import data
zpool import data
root@pve:~# zpool status
pool: data
state: ONLINE
scan: scrub repaired 0B in 00:00:04 with 0 errors on Sun Dec 11 00:24:05 2022
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi4 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 ONLINE 0 0 0
errors: No known data errors
In dem Fall sind wir sauber raus unsere Daten sind noch da, nur die Konfiguration muss noch wiederhergestellt werden. Falls nur einen Disk kaputt ist werden Sie nach dem Import folgendes bekommen
zpool status -v
pool: data
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using ‚zpool replace‘.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: scrub repaired 0B in 00:00:04 with 0 errors on Sun Dec 11 00:24:05 2022
config:
NAME STATE READ WRITE CKSUM
data DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
7723795709861257045 UNAVAIL 0 0 0 was /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi4-part1
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 ONLINE 0 0 0
Den defekten Disk austauschen und dann den zpool reparieren
zpool replace -f data 7723795709861257045 /dev/sdd
root@pve:~# zpool status -v
pool: data
state: DEGRADED
scan: resilvered 213M in 00:00:04 with 0 errors on Sun Dec 11 14:25:56 2022
config:
NAME STATE READ WRITE CKSUM
data DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
7723795709861257045 FAULTED 0 0 0 was /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi4-part1
sdd ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 ONLINE 0 0 0
errors: No known data errors
Wie Sie hier sehen der defekten Disk wird gerade ersetzt, sobald diese Reparatur erfolgt ist haben wir wieder einen sauberen ZFS pool
zpool status -v
pool: data
state: ONLINE
scan: scrub repaired 0B in 00:00:03 with 0 errors on Sun Dec 11 14:26:09 2022
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdd ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 ONLINE 0 0 0
errors: No known data errors
Wenn zwei oder mehr Disks zerstört wurden, müssen Sie den ZFS Pool wieder komplett erstellen inklusiv aller vdev’s Hilfe können Sie dabei in der letzter Backup Log bekommen. Wenn alles wieder hergestellt ist können wir zur nächsten Schritt gehen
3.3 - Wiederherstellung der Daten in den ZFS Pool
Falls der ZFS Pool auch zerstört wurde, musst er wiederhergestellt werden. Falls Sie Ihre Konfiguration nicht irgendwo Parat haben oder nicht mehr wissen wie diese war. Können Sie unter /backup/pvetest/config die letzte Backup datei nach root kopieren
mkdir -p /root/restore
cp /backup/pvetest/config/proxmox_backup_pve.netwitch.de_2022-12-11.14.53.47.tar.gz /root/restore
cd /root/restore
tar -xvzf proxmox_backup_pve.netwitch.de_2022-12-11.14.53.47.tar.gz
tail -100 var/tmp/proxmox-P6ewPaJB/proxmoxreport.2022-12-11.19.18.14.txt
# zpool status
pool: data
state: ONLINE
scan: scrub repaired 0B in 00:00:04 with 0 errors on Sun Dec 11 00:24:05 2022
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
errors: No known data errors
# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
data 79.5G 869M 78.7G – – 0% 1% 1.00x ONLINE –
raidz1-0 79.5G 869M 78.7G – – 0% 1.06% – ONLINE
sdd 20.0G – – – – – – – ONLINE
sde 20.0G – – – – – – – ONLINE
sdf 20.0G – – – – – – – ONLINE
sdg 20.0G – – – – – – – ONLINE
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 650M 57.0G 32.9K /data
data/vm 649M 57.0G 34.4K /data/vm
data/vm/subvol-100-disk-0 324M 11.7G 324M /data/vm/subvol-100-disk-0
data/vm/subvol-110-disk-0 324M 11.7G 324M /data/vm/subvol-110-disk-0
Hier haben Sie die Informationen, anhand diese können Sie Ihre ZFS Pool neu erstellen, (Anleitung steht unter ZFS Konfiguration in die Anleitung )
Wenn das Pool wiederhergestellt wurde sollte es wieder in den WEB Frontend zur Verfügung stehen, falls nicht müssen Sie auch dieser Punkt manuell erzeugen wenn es nach wie vor nicht mehr da ist nach der Restaurierung der konfiguration.
Jetzt geht es darum unsere Daten aus dem Backup zurück zu holen. Zuerst lassen wir uns zeigen welche Backup wir da haben und nehmen den letzten
root@pve:~/bin# borg list /backup/pvetest/borgbackup/
Enter passphrase for key /backup/pvetest/borgbackup:
20221211_210728 Sun, 2022-12-11 21:07:29 [0c6720223308ffefc883a4ea5408157819cd69819f68743cc94e73708b7d2c00]
Jetzt können wir dieses backup mounten
root@pve:~/bin# mkdir /restore
root@pve:~/bin# borg mount /backup/pvetest/borgbackup::20221211_210728 /restore
Enter passphrase for key /backup/pvetest/borgbackup:
root@pve:~/bin# cd /restore
root@pve:/restore# ll
total 0
drwxr-xr-x 1 root root 0 Dec 11 21:14 data
drwx—— 1 root root 0 Dec 11 20:56 root
Unsere zfs Daten befinden sich unter data, das root Verzeichnis ist nur ein Abbild von /root falls irgendwelche skripte notwendig wären
root@pve:/restore/data/vm# ll
total 0
drwxr-xr-x 1 100000 100000 0 Dec 11 20:09 subvol-100-disk-0
drwxr-xr-x 1 100000 100000 0 Dec 11 20:09 subvol-101-disk-0
Jetzt nur noch die daten zurückspielen
rsync -av /restore/data/vm/ /data/vm/
Das gleiche musst noch mit jeden Verzeichnis unter /restore/data wiederholt werden, dieser restore kann sehr Zeit intensiv sein, mehrere Stunden bis Tage, je nach disk Belegung. Wenn dieses Teil fertig ist, können wir jetzt die Konfiguration wiederherstellen.
3.4 - Wiederherstellung der Konfiguration
Unter /backup/pvetest/config die letzte backup Datei nach /root/bin kopieren
z.B.:
cp /backup/pvetest/config/proxmox_backup_pve.netwitch.de_2022-12-11.14.53.47.tar.gz /root/bin/
cd /root/bin
Die Datei pve_config_restore.sh erstellen
vi pve_config_restore.sh
„esc“ „:i“
#!/bin/bash
# Version 0.2.3
# Date 04.18.2022
# Author razem-io
# Contributors
# Very basic restore script based on https://github.com/DerDanilo/proxmox-stuff/issues/5
# Restores backup from pve_config_backup.sh
# example: pve_config_restore.sh proxmox_backup_proxmoxhostname_2017-12-02.15.48.10.tar.gz
set -e
if [[ $# -eq 0 ]] ; then
echo ‚Argument missing -> restore.sh proxmox_backup_proxmoxhostname_2017-12-02.15.48.10.tar.gz‘
exit 0
fi
FOLDER_1=“./$1_1″
FOLDER_2=“./$1_2″
mkdir „$FOLDER_1“
mkdir „$FOLDER_2“
tar -zxvf $1 -C „$FOLDER_1“
find „$FOLDER_1“ -name „*tar“ -exec tar xvf ‚{}‘ -C „$FOLDER_2“ \;
KONFIGDB=“${FOLDER_1}/*db}
for i in pve-cluster pvedaemon vz qemu-server; do systemctl stop $i ; done || true
cp -avr $FOLDER_2/. /
sqlite3 /var/lib/pve-cluster/config.db „.restore ${KONFIGDB}“
rm -r „$FOLDER_1“ „$FOLDER_2“ || true
rm -rf /etc/pve/*
read -p „Restore complete. Hit ‚Enter‘ to reboot or CTRL+C to cancel.“
shutdown -r
„esc“ „:wq“
chmod 750 pve_config_restore.sh
./pve_config_restore.sh proxmox_backup_pve.netwitch.de_2022-12-11.14.53.47.tar.gz
Und zuletzt booten Sie den Server neu falls der Skript das nicht schon getan hat.
init 6
3.5 - Wiederherstellung der Container und VM’s
Jetzt müssen wir noch überprüfen ob alles wieder funktioniert und vor allem unsere Virtuelle Maschine oder container wiederherstellen falls notwendig
Dazu öffnen wir die Seite in ein Browser https://pve.netwitch.de:8006
Wenne alles da ist dann sind sie schon fertig, zeit für einen Kaffee!
Falls nicht, gibt es noch einiges zu tun, in die linke Spalte clicken Sie auf unseren Backup storage, Falls dieser nicht mehr da sein sollte, müssen Sie es wiederherstellen ( siehe oben unter NFS Anschluß).
Recht davon auf backups und suchen Sie hier nach dem letzten Backup datei für einen Container oder VM, markieren Sie es und klicken oben auf zurückspielen
Wenn in diese letzte Fenster Task OK steht ist die Wiederherstellung fertig und Sie können das Fenster schliessen.
Ihr Server ist wieder da und kann gestartet werden. Das müssen Sie wiederholen für jeden Server bis alles wiederhergestellt ist.
Das war es, aber täuschen Sie sich nicht diese Prozedur ist sehr Zeitintensiv wenn das ZFS pool betroffen war.
4 - Hoch Verfügbarkeit
Eine weitere Lösung ist eine zweite Proxmox PVE server auf zu stellen, den Storage mit CephFS auch hoch Verfügbar konfigurieren, dann Sind Sie in der Lage Ihre Vm oder Container von einen PVE server zur anderen zu verschieben, und der crash einer Server wurde den Betrieb nicht oder nur leicht beeinflussen. Lediglich den defekten Server ersetzen und erneut mit dem vorhandenen synchronisieren, aber so ein setiup wurde den Rahmen diesen Beitrag sprengen, und könnte ein Thema für einen späteren Beitrag werden.