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://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster).

Das Script läßt sich ansonsten auch schnell abwandeln, um ein Backup auf eine externe USB-Platte zu bringen.

#!/bin/bash
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin;  
LOCKFILE=/var/lock/vmbackups.lock;
#
#Hier die UUID der Partition rein, wo die Backups der VMs liegen 
#(blkid benutzen):
UUID="379ed35a-e86b-42a8-b142-8dcbd010e8ca";
#
#Storage-Verzeichnis:
STORAGE1="/var/lib/vz/backups/dump";
STORAGE2="/mnt/backups/dump";
#
#Hier die IDs der Images, die kopiert werden sollen (qm list) (.tar.lzo):
VMID01=100;
VMID02=101;
VMID03=106;
VMID04=200;
#
#Automatische Ermittlung der Dateinamen (letztes Aenderungsdatum) 
(.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);
#
#Zieladresse (pub-key-auth muss funktionieren!):
TARGET1="root@2proxmox :/root/storage1/dump/";
TARGET2="root@2proxmox :/mnt/storage2/dump/";
#
# Diese Prozedur wird nur im Fehlerfall und am Ende aufgerufen:
cleanup() {
rm -f "$LOCKFILE"
exit
}
trap cleanup EXIT TERM INT
#
if lockfile -! -r 0 "$LOCKFILE"; then echo "VM-Backup auf proxmox2 kontrollieren" | mail -s "VM-Backup-Warnung" root
exit 1
fi
#
if ! USB="$(/sbin/findfs UUID=$UUID)" ;
then echo "VM-Dump-Platte auf proxmox1 kontrollieren" | mail -s "VM-Backup-Warnung" root
exit 1
else
#Auf Proxmox1:
DAY="$(date +%u)"
case "$DAY" in 
1) scp $STORAGE1/$IMAGE1 $TARGET2; ;;
2) scp $STORAGE1/$IMAGE2 $TARGET2; ;;
3) scp $STORAGE1/$IMAGE3 $TARGET2; ;;
4) scp $STORAGE1/$IMAGE4 $TARGET2; ;;
5) scp $STORAGE1/$IMAGE1 $TARGET2; ;;
6) scp $STORAGE1/$IMAGE2 $TARGET2; ;;
7) scp $STORAGE1/$IMAGE3 $TARGET2; ;;
*) echo "Falscher Wochentag?";;
esac
# Nagios soll nach dem Backup checken, wie voll die Platte ist:
# /usr/lib/nagios/plugins/check_disk -c 5% -w 20% $USB (( $? == 1 )) && /usr/lib/nagios/plugins/check_disk -c 5% -w 20% $USB | mail -s "200 GB Backup-Platte fast voll" root
fi
#EOf

#Die VM kann auf dem 2. proxmox-Server wieder entpackt und zwangsweise mit der gleichen ID versehen werden (mit "screen" läuft es im Hintergrund ab): 
#(screen) /usr/sbin/qmrestore /mnt/storage2/dump/KVM.tar.lzo <ID> -storage local

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://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster :„Although in the case of two-node clusters it is recommended to use a third, shared quorum disk partition, Proxmox VE 3.4 allows to build the cluster without it. This is NOT possible for Proxmox VE 4.0 and not intended for any Proxmox VE distributions and the better way is to add at least a third node to get HA.“

Für die Linuxmuster-Umgebung ist das Szenario mit mehr als 2 Proxmox-Servern etwas überdimensioniert, so dass sich eine andere Vorgehensweise bewährt hat: Man installiert einen 2. Proxmox-Server (in unserem Fall auf wesentlich schwächerer Hardware als das Produktivsystem). Die beiden Proxmox-Server befinden sich im gleichen Subnetz und können sich gegenseitig per ssh erreichen. Nun kommen zwei Scripte zum Einsatz, die die angelegten Dumps von Server1 (Produktivsystem) nachts auf Server2 (Backupsystem) kopieren.

Zunächst lädt man sich das Backup-Script herunter: http://stefan.blochberger.de/serendipity/index.php?/archives/20-Backup-Skript-mit-eMail-Funktion.html (greift auf rsync zurück). Der Vorteil dieses Scriptes liegt darin, dass es die Option „-d“ besitzt. Bedeutung:-d x „Alte Backup-Dateien die älter als x Tage sind löschen“. Daher läuft auf Server2 nicht automatisch das Backup-Storage voll, sondern man hält immer nur Dumps der letzten x Tage bereit. Da sich die Dateinamen der Dumps immer ändern und mit einer aktuellen Datumsangabe versehen werden, hat sich dieser Weg als praktikabel erwiesen.

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, so dass man auch hier direkt sowas wie eine Versionskontrolle hat.

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 „Garantie“, dass das Backup-Storage nicht versehentlich mit der Zeit voll läuft!

Der Cronjob auf Server1 lautet:

0 15 * * *  /scripte/backup-tux/backup_pve_auf_2proxmox.sh

Der Inhalt von Script 1:

#!/bin/bash
#set -x
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
LOCKFILE=/var/lock/vm_to_proxmox_2_backup.lock

# Diese Prozedur wird nur im Fehlerfall und am Ende aufgerufen:
cleanup() {
        rm -f "$LOCKFILE"
        exit
       }
trap cleanup EXIT TERM INT

if lockfile -! -r 0 "$LOCKFILE"; then echo "PVE-Backup (VMs) kontrollieren" #| mail -s "Backup-Warnung" root
exit 1
fi

#NFS-Share einhängen:
umount /mnt/pve/proxmox-2-dump
mount -t nfs 192.168.10.50:/mnt/raid10 /mnt/pve/proxmox-2-dump/ -o nfsvers=3,nolock
sleep 3
#Sicherheitsabfrage, ob erfolgreich gemountet wurde:
       mount | grep /mnt/pve/proxmox-2-dump
       if [ $? -ne 0 ] ; then
        #mail -s "mount failed" root
            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:
    /scripte/backup-tux/backup-321tux.sh -p 1 -d 4
    umount /mnt/pve/proxmox-2-dump
       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: /etc/exports enthält die Zeile: <blockquote>/mnt/raid10/ 192.168.10.0/24(rw,async,no_root_squash,no_subtree_check)</blockquote> und ist somit via NFS freigegeben.

Nach der Backup-Prozedur wird das Share direkt wieder per umount „entfernt“. Läßt man es gemountet, ergeben sich manchmal unerwünschte „Verzögerungen“. Der Aufruf des backup-tux-sh-Sriptes erfolgt mit den Parametern -p 1 (1. Profil wird verwendet) sowie -d 4 (s.o.).

Das Profil sieht hier so aus:

# = = Profil 1  = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
 title[1]="VM-Backup"
   arg[1]="1"
source[1]="/mnt/backup/dump"
#target[1]="$MOUNT/mnt/backup-homes"
#NFS-Laufwerk wurde DIREKT selbst gemountet -- daher ohne $MOUNT
target[1]="/mnt/pve/proxmox-2-dump"
   log[1]="${target[1]}/dump/${title[1]}-log.txt"
exfrom[1]="$(mktemp -t "tmp.rsync.XXXX")"
rsync_opt[1]=""
cat > "${exfrom[1]}" <<EOF
EOF

Auf Server2 liegen die Backups nach dem Durchlauf des 1. Scriptes nun auf einem der Storages (hier /mnt/raid10), die für Backups zur Verfügung stehen (Rechenzentrum → Storage → Inhalt festlegen). Man kann diese Backups nun entweder per Webinterface einzeln entpacken/wiederherstellen oder man setzt das unten aufgeführte 2. Script ein, das alles in einem Rutsch erledigt. Last man dieses Script regelmäßig per Cronjob laufen, sind beide Server synchron (Zeitpunkt des letzten Backups!).

#!/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   02.07.2015    M. Hagedorn  
############################################################################
#Eigene Einstellungen:

#Pfad für die VM-Dumps auf dem Backup-Server:
pfad='/mnt/raid10/dump/'
images='/mnt/raid10/images/'

#Wohin sollen die VMs zurückgespielt werden?
storage='raid10'

#IDs der VMs, die automatisch restored werden sollen:
#(Liste aller VMs mit "qm list" anzeigen lassen)
VM="500 501 502 503 504 506 600"

#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- '{if(m[$3]<$0)m[$3]=$0;} END {for(x in m){print x " " m[x];}}'

cd $pfad

for i in $VM; do
#IDs:
ID=$(ls *.vma.* | awk -F- '{if(m[$3]<$0)m[$3]=$0;} END {for(x in m){print x " " m[x];}}' |cut -f1 -d" " |grep $i);

#zugehörige neuesten Dateinamen:
filename=$(ls *.vma.* | awk -F- '{if(m[$3]<$0)m[$3]=$0;} END {for(x in m){print x " " m[x];}}' |cut -f2 -d" " |grep $i);

#Restore (Vorsicht mit selbst umbenannten VMs!)
echo "screen qmrestore $filename $ID -force -storage $storage";
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' '  '{ print "VM: " $9 "     Backup vom: " $6 " "$7 }' >> last_sync_VMs.txt
ls -ld $images/$ID | awk -F' '  '{ print "VM: " $9 "     synchronisiert am: " $6 " "$7 }' >> last_sync_VMs.txt
done

#Backup manuell  
#screen vzdump 500 --remove 0 --mode snapshot --compress lzo --storage storage2 --node proxmox2 --tmpdir /mnt/raid10/tmp/

Der zugehörige Cronjob auf Server2 sieht so aus:

0 21 * * * /scripte/vm_komplettrestore.sh

In dem 2. Script unten wird die Option „-force“ benutzt, um ganz sicher zu gehen, dass die VMs auf beiden Servern die gleiche ID bekommen! Das bedeutet allerdings auch, dass eine bereits vorhandene VM mit der gleichen ID auf Server2 überschrieben wird!!! Das sollte man wissen, wenn man auf Server2 andere VMs betreibt oder andere IDs benutzt hat als auf Server1!!!

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 „nur“ noch die Kabel zum grünen/blauen Netz von Server 1 an Server 2 anklemmen. Nun kann man Server1 reparieren/umbauen und später wieder in Betrieb nehmen. Es sollte nicht unerwähnt bleiben, dass der Datenbestand in der Zwischenzeit natürlich wieder auseinanderlaufen kann – je nachdem wie lange Server1 außer Betrieb bleibt. Daher muss man nach getaner Arbeit je nach Bedeutung der Daten, die in der Zwischenzeit entstanden sind, die neuen Dumps wieder zurück nach Server1 kopieren und kann sie dort wieder entpacken. Diesen letzten Schritt leistet diese Scripte allerdings (noch?) nicht!

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.