10
KVM: Backup einer VM im laufenden Betrieb
Wie macht man im laufenden Betrieb per Kommandozeile ein Backup einer KVM Virtuellen Maschine ohne das der Betrieb beeinträchtigt wird? Die Lösung heißt "virsh blockcopy". Dazu sollte auf dem KVM Host der Befehl "virsh" installiert sein (Unter Ubuntu:
Der Vorgang wurde unter Ubuntu 14.04.1 getestet, sollte aber auf jedem System mit "virsh" funktionieren.
Hier die einzelnen Schritte (als Root User oder per sudo davor):
VMNAME = Name der VM
/backup = Verzeichnis, wo das Backup-Image und die Backup-Konfiguration gespeichert wird
Als erstes muss man die zu sichernde VM identifizieren:
Jetzt sichert man die aktuelle Konfiguration der VM in ein XML-File:
Der folgenden Befehl zeigt die Image Datei und den Pfad der VM an (nur zur Info und zum überprüfen ob vda das richtige Image ist):
Jetzt muss man die Virtuelle Maschine auf "undefine" setzten. Das ist zwar unelegant, da man die VM aus dem Management der Maschine löst, wir fügen sie aber nach dem Backup wieder hinzu (per virsh define siehe letzter Schritt). Dafür haben wir vorher die XML-Konfiguration per xmldump gesichert (an der Behebung dieses Schrittes wird bereits aktiv in der KVM-Community gearbeitet. Es gibt bereits erste Patches. Noch muss man aber diesen Schritt machen).
Jetzt kann man die VDA sichern und die VM läuft einfach munter weiter:
Jetzt fügen wir die VM wieder dem Management hinzu:
Fertig. Ihr habt jetzt ein komplettes Backup eurer laufenden VM ohne Betriebsunterbrechung im Backup Verzeichnis "/backup/VMNAME_backup.qcow2"
Gruß
Frank
sudo apt-get install virtinst libvirt-bin).Der Vorgang wurde unter Ubuntu 14.04.1 getestet, sollte aber auf jedem System mit "virsh" funktionieren.
Hier die einzelnen Schritte (als Root User oder per sudo davor):
VMNAME = Name der VM
/backup = Verzeichnis, wo das Backup-Image und die Backup-Konfiguration gespeichert wird
Als erstes muss man die zu sichernde VM identifizieren:
virsh list
Id Name Status
----------------------------------------------------
11 VMNAME laufend
virsh dumpxml --inactive --security-info VMNAME > /backup/VMNAME.xml
virsh domblklist VMNAME
Ziel Quelle
------------------------------------------------
vda /var/lib/libvirt/images/VMNAME.qcow2
hda -
virsh undefine VMNAME
virsh blockcopy VMNAME vda /backup/VMNAME_backup.qcow2 --wait --finish --verbose
virsh define /backup/VMNAME.xml
Fertig. Ihr habt jetzt ein komplettes Backup eurer laufenden VM ohne Betriebsunterbrechung im Backup Verzeichnis "/backup/VMNAME_backup.qcow2"
Gruß
Frank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 255843
Url: https://administrator.de/knowledge/kvm-backup-einer-vm-im-laufenden-betrieb-255843.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
ich bekomme nach folgendem Schritt:
root@fc:~# virsh blockcopy fc-groupoffice vda /media/michael/SSD/backup/fc-groupoffice_backup.img --wait --finish --verbose
diese Fehlermeldung
error: internal error: unable to execute QEMU command 'drive-mirror': Could not create file: Permission denied
Das Zielverzeichnis hat aber die richtigen Rechte, da ja das kopieren der xml Datei auch funktioniert hat.
Was könnte das sein?
Danke!
Michael
ich bekomme nach folgendem Schritt:
root@fc:~# virsh blockcopy fc-groupoffice vda /media/michael/SSD/backup/fc-groupoffice_backup.img --wait --finish --verbose
diese Fehlermeldung
error: internal error: unable to execute QEMU command 'drive-mirror': Could not create file: Permission denied
Das Zielverzeichnis hat aber die richtigen Rechte, da ja das kopieren der xml Datei auch funktioniert hat.
Was könnte das sein?
Danke!
Michael
Hi Michael,
sieht auf jeden Fall nach Rechteproblem aus. "/media/michael/SSD/backup/fc-groupoffice_backup.img" kann wohl nicht geschrieben werden. In der Meldung steht folgendes: "Could not create file: Permission denied". D.h. er kann die Backupdatei "fc-groupoffice_backup.img" nicht erstellen.
Gruß
Frank
sieht auf jeden Fall nach Rechteproblem aus. "/media/michael/SSD/backup/fc-groupoffice_backup.img" kann wohl nicht geschrieben werden. In der Meldung steht folgendes: "Could not create file: Permission denied". D.h. er kann die Backupdatei "fc-groupoffice_backup.img" nicht erstellen.
Gruß
Frank
Hi Frank,
danke für deine rasche Antwort.
Was ich nicht verstehe ist, dass der vorherige Schritt "virsh dumpxml --inactive --security-info VMNAME > /backup/VMNAME.xml" tadellos funktioniert hat und eben die XML-Datei genau in diesem Verzeichnis liegt, ohne Erstellungsproblemen (siehe Screenshot).
Das kann doch nicht sein, dass es zuerst funktioniert und beim zweiten Mal nicht mehr!?
Grüße!
Michael
danke für deine rasche Antwort.
Was ich nicht verstehe ist, dass der vorherige Schritt "virsh dumpxml --inactive --security-info VMNAME > /backup/VMNAME.xml" tadellos funktioniert hat und eben die XML-Datei genau in diesem Verzeichnis liegt, ohne Erstellungsproblemen (siehe Screenshot).
Das kann doch nicht sein, dass es zuerst funktioniert und beim zweiten Mal nicht mehr!?
Grüße!
Michael
Hi,
prüfe das mal:
und
Du meinst, dass du die Datei: "/media/michael/SSD/backup/fc-groupoffice.xml" anlegen konntest? Prüfe mal, ob es wirklich das gleiche Verzeichnis ist.
Wie sehen denn dein Rechte in diesem Verzeichnis aus? Schon einmal die Rechte zum Testen geändert?
Gruß
Frank
prüfe das mal:
/media/michael/SSD/backup/fc-groupoffice_backup.imgund
/backup/VMNAME.xmlDu meinst, dass du die Datei: "/media/michael/SSD/backup/fc-groupoffice.xml" anlegen konntest? Prüfe mal, ob es wirklich das gleiche Verzeichnis ist.
Wie sehen denn dein Rechte in diesem Verzeichnis aus? Schon einmal die Rechte zum Testen geändert?
Gruß
Frank
Aktuellere libvirt/qemu versionen bringen mittlerweile neue Features mit um Virtuelle Maschinen im laufenden Betrieb ordentlich absichern zu können, unter anderem erweitern diese Features den Umfang auch um Incrementielle sowie Differentielle Sicherungstypen.
Man sollte ausserdem nicht ausser Acht lassen dass eine Virtuelle Maschine in heutiger zeit auch oftmals über UEFI gebootet wird und zusätzlich zum einfachen Disk backup auch noch andere Einstellungen wie die UEFI BIOS Settings mitgesichert werden sollten (stichwort Secure Boot).
Darüberhinaus ist es auch Sinnvoll innerhalb der VM den QEMU Guest Agent installiert zu haben, damit wärend der entsprechenden Sicherungsoperationen die Dateisysteme innerhalb der VM ordentlich stillgelegt werden können, sonst ist die Sicherung nur "Crash consistant", was unter anderem bei einer Rücksicherung zu inkonsistenzen im Dateisystem führen kann (oder im schlimmsten Falle z.B. zu inkonsistenten Datenbanken die innerhalb der VM betrieben werden.
Hier ein Freies Projekt das ein Backup Utility für Libvirt erstellt hat das die neuen Sicherungsmethoden unterstützt: https://github.com/abbbi/virtnbdbackup
Man sollte ausserdem nicht ausser Acht lassen dass eine Virtuelle Maschine in heutiger zeit auch oftmals über UEFI gebootet wird und zusätzlich zum einfachen Disk backup auch noch andere Einstellungen wie die UEFI BIOS Settings mitgesichert werden sollten (stichwort Secure Boot).
Darüberhinaus ist es auch Sinnvoll innerhalb der VM den QEMU Guest Agent installiert zu haben, damit wärend der entsprechenden Sicherungsoperationen die Dateisysteme innerhalb der VM ordentlich stillgelegt werden können, sonst ist die Sicherung nur "Crash consistant", was unter anderem bei einer Rücksicherung zu inkonsistenzen im Dateisystem führen kann (oder im schlimmsten Falle z.B. zu inkonsistenten Datenbanken die innerhalb der VM betrieben werden.
Hier ein Freies Projekt das ein Backup Utility für Libvirt erstellt hat das die neuen Sicherungsmethoden unterstützt: https://github.com/abbbi/virtnbdbackup
1
Zitat von @abbbbi:
Aktuellere libvirt/qemu versionen bringen mittlerweile neue Features mit um Virtuelle Maschinen im laufenden Betrieb ordentlich absichern zu können, unter anderem erweitern diese Features den Umfang auch um Incrementielle sowie Differentielle Sicherungstypen.
Man sollte ausserdem nicht ausser Acht lassen dass eine Virtuelle Maschine in heutiger zeit auch oftmals über UEFI gebootet wird und zusätzlich zum einfachen Disk backup auch noch andere Einstellungen wie die UEFI BIOS Settings mitgesichert werden sollten (stichwort Secure Boot).
Darüberhinaus ist es auch Sinnvoll innerhalb der VM den QEMU Guest Agent installiert zu haben, damit wärend der entsprechenden Sicherungsoperationen die Dateisysteme innerhalb der VM ordentlich stillgelegt werden können, sonst ist die Sicherung nur "Crash consistant", was unter anderem bei einer Rücksicherung zu inkonsistenzen im Dateisystem führen kann (oder im schlimmsten Falle z.B. zu inkonsistenten Datenbanken die innerhalb der VM betrieben werden.
Hier ein Freies Projekt das ein Backup Utility für Libvirt erstellt hat das die neuen Sicherungsmethoden unterstützt: https://github.com/abbbi/virtnbdbackup
Aktuellere libvirt/qemu versionen bringen mittlerweile neue Features mit um Virtuelle Maschinen im laufenden Betrieb ordentlich absichern zu können, unter anderem erweitern diese Features den Umfang auch um Incrementielle sowie Differentielle Sicherungstypen.
Man sollte ausserdem nicht ausser Acht lassen dass eine Virtuelle Maschine in heutiger zeit auch oftmals über UEFI gebootet wird und zusätzlich zum einfachen Disk backup auch noch andere Einstellungen wie die UEFI BIOS Settings mitgesichert werden sollten (stichwort Secure Boot).
Darüberhinaus ist es auch Sinnvoll innerhalb der VM den QEMU Guest Agent installiert zu haben, damit wärend der entsprechenden Sicherungsoperationen die Dateisysteme innerhalb der VM ordentlich stillgelegt werden können, sonst ist die Sicherung nur "Crash consistant", was unter anderem bei einer Rücksicherung zu inkonsistenzen im Dateisystem führen kann (oder im schlimmsten Falle z.B. zu inkonsistenten Datenbanken die innerhalb der VM betrieben werden.
Hier ein Freies Projekt das ein Backup Utility für Libvirt erstellt hat das die neuen Sicherungsmethoden unterstützt: https://github.com/abbbi/virtnbdbackup
Dir ist schon klar das du auf einen Beitrag von 2014/2016 geantwortet hast um deine eigene Software zu promoten oder?
Angesprochen hast du ein BIOS Backup. Wo ist es denn?
Das geht auch nur bei deiner Lösung wenn sowas wer explizit mit als Datei/Image eingebaut hat.
Ansonsten kannst du auch mit deinem Programm das BIOS nicht sichern.
Und warum überhaupt dein Tool verwenden wenn es doch modernere Methoden gibt die fest implementiert sind!!!
* virsh dumpxml VM1 > /pfad/VM1.xml (um die Konfiguration zu sichern)
* virsh backup-begin VM1
- virsh backup-begin VM1 (Status anzeigen)
Vergiss bitte auch nicht alle Netzwerke!!!
networks=$(virsh domiflist "VM1" | grep network | tr -s ' ' | awk '{ print $3}')
for network in $networks; do
virsh net-dumpxml "$network" > '$network'.xml'
done
ich mach das noch auf die alte Art mit snapshot/rync und blockcommit. Aber extra noch was eigenes entwickeln braucht man eigentlich nicht mehr wenn alles schon dabei ist.
Quote from @TorbenM:
Dir ist schon klar das du auf einen Beitrag von 2014/2016 geantwortet hast um deine eigene Software zu promoten oder?
Dir ist schon klar das du auf einen Beitrag von 2014/2016 geantwortet hast um deine eigene Software zu promoten oder?
dieser Beitrag mag für seine Zeit angemessen gewesen sein, aktuellere Libvirt/QEMU Versionen bieten
aber weitaus bessere methoden Sicherungen anzufertigen, im laufenden Betrieb, mit konsistentem
Ergebnis. Zumal der Beitrag in Suchmaschinen immer noch recht weit oben auftaucht, wäre ein
Update einmal angebracht.
Angesprochen hast du ein BIOS Backup. Wo ist es denn?
Das geht auch nur bei deiner Lösung wenn sowas wer explizit mit als Datei/Image eingebaut hat.
Ansonsten kannst du auch mit deinem Programm das BIOS nicht sichern.
Das geht auch nur bei deiner Lösung wenn sowas wer explizit mit als Datei/Image eingebaut hat.
Ansonsten kannst du auch mit deinem Programm das BIOS nicht sichern.
es geht hier darum wie die Virtuelle maschine bootet. Verwendet die VM OVM als Bootloader werden
die UEFI Setting von Libvirt in einer zusätzlichen Datei ausgelagert (nvram). Hat die VM secureboot
konfiguriert und diese Settings werden nicht explizit mitgesichert und man verliert das Hostystem hat
man unter Umständen ein etwas grösseres Problem.
Und warum überhaupt dein Tool verwenden wenn es doch modernere Methoden gibt die fest implementiert sind!!!
weil es ganz einfach keine Vollständige, konsistente Sicherungsmethode ist die unter Umständen
zu richtigem Datenverlust führt. (backup-begin, das im Artikel nicht behandlet wird, ist im übrigen dann per
default die Push methode, die Daten werden wenn nicht anders angegeben einfach auf dem HV "gespuckt"):
Man will aber ggf die Daten auf andere Hosts sichern: daher gibt es auch die die pull basierte methode. Die Implementation der PULL based Methode ist sache der Sicherungssofware, hier muss die Sicherungssoftware
auslesen welche Blöcke zur Sicherung benötigt werden und welche nicht. Auch wie die entsprechenden
angelegten checkpoints für die auf einer Full sicherung aufbauenden Sicherungsketten logisch
zusammenpassen ist dann implementationssache.
ich mach das noch auf die alte Art mit snapshot/rync und blockcommit. Aber extra noch was eigenes entwickeln braucht man eigentlich nicht mehr wenn alles schon dabei ist.
rsync/blockcommit erlaubt es dir nicht konsistente *incrementielle* oder *differentielle* Sicherungen
durchzuführen. Auch wenn rsync nur die geänderten blöcke überträgt muss es doch die ganze disk
der Virtuellen maschine lesen und änderungsdaten vergleichen. Eine Kleine VM mit 1 GB ist da kein Problem,
bei Virtuellen Maschinen deren Datenmengen an die 500GB oder 1 TB haben, ist das aber kein sinnvoller
Ansatz mehr. Auch ist es dir nicht möglich mit derartigem vorgehen ein Point in Time recovery durchzuführen
was unter Umständen nötig ist wenn die Virtuelle Maschine *logischen* Datenverlust erhalten hat.
Wohlgemerkt wurden auch Libvirt sowie QEMU in dieser Hinsicht massiv weiterentwickelt, um eben auch
im Professionellen, Kommerziellen Umfeld als Konkurrenz zu VMware oder anderen Hypervisorn die
derartige Sicherungsmethoden schon lange unterstützen mithalten zu können:
https://libvirt.org/kbase/live_full_disk_backup.html
Ob und wie ich meine (wohlgemerkt GPL lizensierte) Software Promote, muss dir nicht übel aufstossen,
diese ist übrigens kein "ersatz"für die von dir genannten libvirt/qemu versionen sondern eine *ergänzung*
um die Features angenehm und einfach nutzen zu können.
Schönen Tag noch.
Willst du jetzt alle Beiträge von damals nochmal korrigieren???
Weil überall gibt es "neue Technologien" ...
Der Beitrag taucht relativ häufig auf weil DU hier gepostet hast.
Wegen dem UEFI Bios spielt das nur eine Rolle wenn man eigene Dinge implementiert.
Bei der Standart Konfiguration ist das egal. Da kannste auch den HOST neu installieren.
Dir ist klar das man das Backup der gängigen Methode danach irgend wo hin übertragen kann oder?
Direkt während des Backups sorgt für ziemlich viel Traffic und ist langsam. Kann ja auch fehlschlagen.
Ich mache NUR Vollsicherungen und möchte nichts anderes.
Wenn deine Disks größer sind. z.B 500 GB oder 1 TB hast du ein falsches Konzept. System Images haben klein zu sein. 64 GB ist gängig. Selbst die ORACLE Cloud erstellt standartmäßig 50 GB Disks. Hier auf der Arbeit 40 GB. Zu Hause hab ich bei manchen 6 GB.
Absolut NIEMAND braucht größere Images. Dann hast du das Konzept von VM/Storage-Server/File-Server noch nicht verstanden.
Ok wenn das hier niemanden stört mit Werbung machen.. Promote ich auch mal mein eigenes kleines Backup Script. Ist aber noch lange nicht perfekt.
Das kann sogar laufende VMs sichern wenn man das Image löscht.
https://pastebin.com/URrtG3hP
Schönen Tag noch.
Weil überall gibt es "neue Technologien" ...
Der Beitrag taucht relativ häufig auf weil DU hier gepostet hast.
Wegen dem UEFI Bios spielt das nur eine Rolle wenn man eigene Dinge implementiert.
Bei der Standart Konfiguration ist das egal. Da kannste auch den HOST neu installieren.
Dir ist klar das man das Backup der gängigen Methode danach irgend wo hin übertragen kann oder?
Direkt während des Backups sorgt für ziemlich viel Traffic und ist langsam. Kann ja auch fehlschlagen.
Ich mache NUR Vollsicherungen und möchte nichts anderes.
Wenn deine Disks größer sind. z.B 500 GB oder 1 TB hast du ein falsches Konzept. System Images haben klein zu sein. 64 GB ist gängig. Selbst die ORACLE Cloud erstellt standartmäßig 50 GB Disks. Hier auf der Arbeit 40 GB. Zu Hause hab ich bei manchen 6 GB.
Absolut NIEMAND braucht größere Images. Dann hast du das Konzept von VM/Storage-Server/File-Server noch nicht verstanden.
Ok wenn das hier niemanden stört mit Werbung machen.. Promote ich auch mal mein eigenes kleines Backup Script. Ist aber noch lange nicht perfekt.
Das kann sogar laufende VMs sichern wenn man das Image löscht.
https://pastebin.com/URrtG3hP
Schönen Tag noch.
Quote from @TorbenM:
Willst du jetzt alle Beiträge von damals nochmal korrigieren???
Weil überall gibt es "neue Technologien" ...
Willst du jetzt alle Beiträge von damals nochmal korrigieren???
Weil überall gibt es "neue Technologien" ...
nein, aber es gibt Kommentarfunktionen die zur Diskussion anregen.
Wegen dem UEFI Bios spielt das nur eine Rolle wenn man eigene Dinge implementiert.
Bei der Standart Konfiguration ist das egal. Da kannste auch den HOST neu installieren.
Bei der Standart Konfiguration ist das egal. Da kannste auch den HOST neu installieren.
wo hätte ich denn was anderes behauptet?
Dir ist klar das man das Backup der gängigen Methode danach irgend wo hin übertragen kann oder?
Direkt während des Backups sorgt für ziemlich viel Traffic und ist langsam. Kann ja auch fehlschlagen.
Direkt während des Backups sorgt für ziemlich viel Traffic und ist langsam. Kann ja auch fehlschlagen.
und das schreiben der Daten direkt auf dem host sorgt ebenfalls für I/O, vorallem wenn die Sicherungsdaten
auf das gleiche Volume laufen auf dem auch die Virtuellen maschinen betrieben werden.
Wie garantierst du dass die Sicherungsdaten zwischen Schreiboperation auf dem Host und übertragung auf
deine offsite backup location noch konsistent sind?
Ich mache NUR Vollsicherungen und möchte nichts anderes.
dann kannst du ja zufrieden sein
Wenn deine Disks großer sind. z.B 500 GB oder 1 TB hast du ein falsches Konzept. System Images haben klein zu sein. 64 GB ist gängig. Selbst die ORACLE Cloud erstellt standartmäßig 50 GB Disks. Hier auf der Arbeit 40 GB. Zu Hause hab ich bei manchen 6 GB.
wie gross die eigentlichen Images sind ist ja unerheblich, da die aktuellen Sicherungsmethoden thin
provisioned sichern (auch ein Vorteil gegenüber der rsync variante, denn bei einem thick provisioned Image
muss rsync im übrigen, wenn nicht mit den sparse optionen gearbeitet wird einiges an 0 Blöcken lesen, was
zusätzlich I/O und Zeit kostet.
Absolut NIEMAND braucht größere Images. Dann hast du das Konzept von VM/Storage-Server/File-Server noch nicht verstanden.
natürlich, ganz sicher. Blöd nur wenn ich auch meinen File Server virtuell betreibe und diesen sichern will.
Ok wenn das hier niemanden stört mit Werbung machen.. Promote ich auch mal mein eigenes kleines Backup Script. Ist aber noch lange nicht perfekt.
da habe ich kein Problem damit. Von mir wars das zu dem Thema. Deine Diskussionkultur (mit unterstellungen von Inkompetenzen) ist mir zu aggressiv ausserdem verstehe nicht was für ein "Problem" du
hast. Ist ja jedem freigestellt welche Lösung er verwendet.
Inkompetent unterstelle ich hier nicht.
Ich will lediglich herausfinden warum man schon wieder "etwas neues" nutzen sollte.
Außerdem bin ich eher "minimalistisch" veranlagt.
Ich hab mir deinen Code jetzt nicht so angeschaut aber sieht schon riesig aus.
Wie ich garantiere das Daten noch heile sind?! Rsync prüft das von sich aus alles.
Sparse Files nimmt man NIEMALS bei VMs. Aber für sowas gibts ja auch den Parameter -W eigentlich. Da sollte alles kopiert werden.
Bei einem Fileserver liegen die Files ja nicht auf der Systemplatte.
Ich z.b habe auch einen virtuellen Windows Fileserver der vom Storage die Daten über iscsi bekommt.
So kann ich von der VM ganz normale Backups machen von außen. Und innerhalb der VM gibts regelmäßig Schattenkopien + Volume Level Backups mit Veeam. So sind Daten und VM getrennt und die Daten können eigentlich überall über iscsi wieder eingebunden werden. Migration zu nem anderen Server läuft einfach so durch ohne das irgend was unterbrochen wird oder die VM an Hardware gekoppelt wäre.
Ich will lediglich herausfinden warum man schon wieder "etwas neues" nutzen sollte.
Außerdem bin ich eher "minimalistisch" veranlagt.
Ich hab mir deinen Code jetzt nicht so angeschaut aber sieht schon riesig aus.
Wie ich garantiere das Daten noch heile sind?! Rsync prüft das von sich aus alles.
Sparse Files nimmt man NIEMALS bei VMs. Aber für sowas gibts ja auch den Parameter -W eigentlich. Da sollte alles kopiert werden.
Bei einem Fileserver liegen die Files ja nicht auf der Systemplatte.
Ich z.b habe auch einen virtuellen Windows Fileserver der vom Storage die Daten über iscsi bekommt.
So kann ich von der VM ganz normale Backups machen von außen. Und innerhalb der VM gibts regelmäßig Schattenkopien + Volume Level Backups mit Veeam. So sind Daten und VM getrennt und die Daten können eigentlich überall über iscsi wieder eingebunden werden. Migration zu nem anderen Server läuft einfach so durch ohne das irgend was unterbrochen wird oder die VM an Hardware gekoppelt wäre.
