Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
— | anwenderwiki:virtualisierung:proxmox:backups_sollten_extern_gesichert_werden [2016/02/23 16:31] (aktuell) – angelegt - Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | {{tag> }} | ||
+ | |||
+ | ====== Script / Cronjob zum Sichern von Proxmox-VMs auf einen anderen Server ====== | ||
+ | |||
+ | Dieses Script ist dazu gedacht, die von Proxmox erzeugten Backups einer VM per Cronjob oder Bash-Befehl per ssh auf einen anderen Server (zum Bsp 2. Proxmox) zu kopieren, um im Fall eines Festplattenausfalls schnell an ein Backup heran zu kommen. Voraussetzung ist, dass ssh per Public-Key-Auth. bereits funktioniert. | ||
+ | |||
+ | Alternativ kann man mit Proxmox auch einen Cluster aufbauen (suche z.B. proxmox 2-node-cluster http:// | ||
+ | |||
+ | Das Script läßt sich ansonsten auch schnell abwandeln, um ein Backup auf eine externe USB-Platte zu bringen. | ||
+ | |||
+ | #!/bin/bash | ||
+ | PATH=/ | ||
+ | LOCKFILE=/ | ||
+ | # | ||
+ | #Hier die UUID der Partition rein, wo die Backups der VMs liegen | ||
+ | #(blkid benutzen): | ||
+ | UUID=" | ||
+ | # | ||
+ | # | ||
+ | STORAGE1="/ | ||
+ | STORAGE2="/ | ||
+ | # | ||
+ | #Hier die IDs der Images, die kopiert werden sollen (qm list) (.tar.lzo): | ||
+ | VMID01=100; | ||
+ | VMID02=101; | ||
+ | VMID03=106; | ||
+ | VMID04=200; | ||
+ | # | ||
+ | # | ||
+ | (.vma.lzo): | ||
+ | IMAGE1=$(ls -tr $STORAGE1 | grep $VMID01 | grep lzo | tail -1); | ||
+ | IMAGE2=$(ls -tr $STORAGE1 | grep $VMID02 | grep lzo | tail -1); | ||
+ | IMAGE3=$(ls -tr $STORAGE1 | grep $VMID03 | grep lzo | tail -1); | ||
+ | IMAGE4=$(ls -tr $STORAGE1 | grep $VMID04 | grep lzo | tail -1); | ||
+ | # | ||
+ | # | ||
+ | TARGET1=" | ||
+ | TARGET2=" | ||
+ | # | ||
+ | # Diese Prozedur wird nur im Fehlerfall und am Ende aufgerufen: | ||
+ | cleanup() { | ||
+ | rm -f " | ||
+ | exit | ||
+ | } | ||
+ | trap cleanup EXIT TERM INT | ||
+ | # | ||
+ | if lockfile -! -r 0 " | ||
+ | exit 1 | ||
+ | fi | ||
+ | # | ||
+ | if ! USB=" | ||
+ | then echo " | ||
+ | exit 1 | ||
+ | else | ||
+ | #Auf Proxmox1: | ||
+ | DAY=" | ||
+ | case " | ||
+ | 1) scp $STORAGE1/ | ||
+ | 2) scp $STORAGE1/ | ||
+ | 3) scp $STORAGE1/ | ||
+ | 4) scp $STORAGE1/ | ||
+ | 5) scp $STORAGE1/ | ||
+ | 6) scp $STORAGE1/ | ||
+ | 7) scp $STORAGE1/ | ||
+ | *) echo " | ||
+ | esac | ||
+ | # Nagios soll nach dem Backup checken, wie voll die Platte ist: | ||
+ | # / | ||
+ | fi | ||
+ | #EOf | ||
+ | |||
+ | #Die VM kann auf dem 2. proxmox-Server wieder entpackt und zwangsweise mit der gleichen ID versehen werden (mit " | ||
+ | #(screen) / | ||
+ | |||
+ | |||
+ | ===== Neue Vorgehensweise (Update vom 21.02.2016) ===== | ||
+ | **Bevor man die unten aufgeführten Scripte laufen läßt, sollte man alles einmal genau lesen und verstehen, da sonst unter Umständen Daten gelöscht werden, die man noch haben möchte!** | ||
+ | |||
+ | Unter Proxmox ist es in der Regel so, dass die angefertigten Backups und das laufende System auf ein und demselben Rechner laufen. Man kann aber auch direkt unter Proxmox NFS-Shares einbinden (Rechenzentrum -> Storage -> Hinzufügen -> NFS-Share), damit Backups direkt auf einem anderen Rechner oder einem NAS gespeichert werden. | ||
+ | Zudem bietet Proxmox selbst bereits die Möglichkeit an, VMs zu migrieren, doch benötigt man dazu einen Cluster, der mindestens 3 Nodes umfassen sollte. Von einem 2-Node-Cluster wird sogar explizit abgeraten: | ||
+ | |||
+ | https:// | ||
+ | |||
+ | Für die Linuxmuster-Umgebung ist das Szenario mit mehr als 2 Proxmox-Servern etwas überdimensioniert, | ||
+ | |||
+ | Zunächst lädt man sich das Backup-Script herunter: http:// | ||
+ | |||
+ | |||
+ | Die anzulegenden Backups werden unter Proxmox selbst eingerichtet und angelegt (Rechenzentrum -> Backup -> Hinzufügen --> VMs und Tage anwählen), und zwar so, dass alle VMs, die auch gespiegelt werden sollen, auf dem **gleichen** Storage angelegt werden. Dieses Verzeichnis wird dann komplett von dem Backup-Script auf Server2 gespiegelt. Selbstverständlich ist unter Proxmox auch direkt die Anzahl der zu behaltenden Backups pro VM einstellbar, | ||
+ | |||
+ | Alternativ läßt sich das Backup natürlich auch direkt (manuell) per rsync oder via NFS-Share anlegen. Dann hat man aber wie gesagt nicht die " | ||
+ | |||
+ | Der Cronjob auf Server1 lautet: | ||
+ | 0 15 * * * / | ||
+ | |||
+ | Der Inhalt von Script 1: | ||
+ | #!/bin/bash | ||
+ | #set -x | ||
+ | PATH=/ | ||
+ | LOCKFILE=/ | ||
+ | | ||
+ | # Diese Prozedur wird nur im Fehlerfall und am Ende aufgerufen: | ||
+ | cleanup() { | ||
+ | rm -f " | ||
+ | exit | ||
+ | } | ||
+ | trap cleanup EXIT TERM INT | ||
+ | | ||
+ | if lockfile -! -r 0 " | ||
+ | exit 1 | ||
+ | fi | ||
+ | | ||
+ | #NFS-Share einhängen: | ||
+ | umount / | ||
+ | mount -t nfs 192.168.10.50:/ | ||
+ | sleep 3 | ||
+ | # | ||
+ | mount | grep / | ||
+ | if [ $? -ne 0 ] ; then | ||
+ | #mail -s "mount failed" | ||
+ | exit 1 | ||
+ | else | ||
+ | #Ink. Backup auf proxmox2-NFS-Share - die Option d 4 sorgt dafür, dass die geloeschten Files nur max 4 Tage zurück liegen: | ||
+ | / | ||
+ | umount / | ||
+ | fi | ||
+ | #EOF | ||
+ | |||
+ | |||
+ | Wie man sieht, wird das Ziellaufwerk vom Backup-Script per NFS gemountet und steht so direkt unter Server1 zur Verfügung. Wie ein NFS-Share auf Server2 angelegt wird, wird hier übrigens nicht gezeigt. Nur soviel: / | ||
+ | |||
+ | Nach der Backup-Prozedur wird das Share direkt wieder per umount " | ||
+ | -p 1 (1. Profil wird verwendet) sowie -d 4 (s.o.). | ||
+ | |||
+ | Das Profil sieht hier so aus: | ||
+ | |||
+ | # = = Profil 1 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = | ||
+ | | ||
+ | | ||
+ | source[1]="/ | ||
+ | # | ||
+ | # | ||
+ | target[1]="/ | ||
+ | | ||
+ | exfrom[1]=" | ||
+ | rsync_opt[1]="" | ||
+ | cat > " | ||
+ | EOF | ||
+ | |||
+ | |||
+ | Auf Server2 liegen die Backups nach dem Durchlauf des 1. Scriptes nun auf einem der Storages (hier / | ||
+ | |||
+ | #!/bin/bash | ||
+ | ############################################################################ | ||
+ | # vm_komplettrestore.sh | ||
+ | # Ein Script zum Restore vieler VMs auf einem Notfallserver. | ||
+ | # Es werden nacheinander alle genannten VMs zurückgespielt und so synchron | ||
+ | # mit dem Produktivserver gehalten. | ||
+ | # V1.4 vom | ||
+ | ############################################################################ | ||
+ | #Eigene Einstellungen: | ||
+ | | ||
+ | #Pfad für die VM-Dumps auf dem Backup-Server: | ||
+ | pfad='/ | ||
+ | images='/ | ||
+ | | ||
+ | #Wohin sollen die VMs zurückgespielt werden? | ||
+ | storage=' | ||
+ | | ||
+ | #IDs der VMs, die automatisch restored werden sollen: | ||
+ | #(Liste aller VMs mit "qm list" anzeigen lassen) | ||
+ | VM=" | ||
+ | | ||
+ | #Zeit, die zwischen zwei Restores gewartet wird: | ||
+ | #SEC=0 | ||
+ | #VM 500 ist zZ am größten und brauchte ~1950 Sekunden! | ||
+ | #Es können aber mehrere VMs gleichzeitig zurückgespielt werden! | ||
+ | SEC=300 | ||
+ | ############################################################################ | ||
+ | | ||
+ | #Syntax (findet paarweise immer die neuere Datei der Backups) | ||
+ | #ls *.vma.* | awk -F- ' | ||
+ | | ||
+ | cd $pfad | ||
+ | | ||
+ | for i in $VM; do | ||
+ | #IDs: | ||
+ | ID=$(ls *.vma.* | awk -F- ' | ||
+ | | ||
+ | # | ||
+ | filename=$(ls *.vma.* | awk -F- ' | ||
+ | | ||
+ | #Restore (Vorsicht mit selbst umbenannten VMs!) | ||
+ | echo " | ||
+ | screen qmrestore $filename $ID -force -storage $storage | ||
+ | sleep $SEC | ||
+ | | ||
+ | #Anzeigen, wann die VM zuletzt synchronisiert wurde und in Log-Datei schreiben: | ||
+ | ls -ld *.vma.* | awk -F' ' | ||
+ | ls -ld $images/$ID | awk -F' ' | ||
+ | done | ||
+ | | ||
+ | #Backup manuell | ||
+ | #screen vzdump 500 --remove 0 --mode snapshot --compress lzo --storage storage2 --node proxmox2 --tmpdir / | ||
+ | |||
+ | |||
+ | Der zugehörige Cronjob auf Server2 sieht so aus: | ||
+ | 0 21 * * * / | ||
+ | |||
+ | ===== ACHTUNG ===== | ||
+ | ** In dem 2. Script unten wird die Option " | ||
+ | |||
+ | Nachdem Script 2 durchgelaufen ist, sind alle eingestellten VMs auf **beiden** Servern auf einem identischen Stand (und zwar natürlich der Zeitpunkt vom zuletzt durchgeführten **Proxmox-**Backup!). Im Fall eines Desasters oder eines Hardwaredefektes auf Server1 muss man nun " | ||
+ | |||
+ | Man kann sich auf Server2 (ssh) ganz am Schluss mit dem Befehl | ||
+ | qm list | ||
+ | anzeigen lassen, welche VMs existieren und unter welchen IDs sie zu erreichen sind. | ||
+ | |||