VirtualBox: Automatische Backups - Zuverlässig & sicher
lima-city → Forum → Heim-PC → Software
apache
code
datei
datenbank
datum
fehler
funktionieren
http
kopie
kopieren
moment
packen
problem
server
speichern
subversion
system
test
url
wiederherstellen
-
Hallo,
Ich habe eine Server-VM, die regelmäßiger Backups bedarf. Da in dieser VM wichtige Daten gespeichert sind und auch fortlaufend dazukommen, ist es sehr wichtig, dass diese Backups sicher und zuverlässig funktionieren. Und da es ein Server ist, ist es ebenfalls wuchtig, dass er nicht allzu lange down ist während ein Backup läuft.
Es gibt unzählige Threads zum Thema Backups von VirtualBox-VMs und das ist wirklich kein einfaches Thema. Man liest immer wieder, dass ganze VMs durch Backup-Scripts zerstört werden und das kann ich mir wirklich nicht leisten.
Leider konnte ich bis jetzt noch keine brauchbare Lösung dazu finden.
Ich hoffe, jemand kann mir da weiterhelfen.
Vielen Dank im Voraus! -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
tchab schrieb:
Script schreiben …
1. VM aus
2. Dateien kopieren.
3. VM an.
3. Dateien packen.
4. Dateien löschen, Archiv speichern.
(Edit)
5. Für maximale Sicherheit per rsync oder sftp auf andere Server laden.
… und per Crontab ausführen.
Danke für deine Antwort!
Funktioniert das bei dir so? Bei mir nicht. Ich habs genau so natürlich schon versucht.
Ich hab genau das schon ausprogrammiert (Konsolenanwendung die man als Task planen kann), aber es hat nicht funktioniert. Zwar sind bis jetzt keine Schäden an der originalen VM aufgetreten, aber ich habe es nicht geschafft die VM in einer anderen Test-VM zu starten.
Dann hab ich mal versucht den Ordner während die VM aus war manuell in die Test-VM zu kopieren, jedoch mit dem gleichen Resultat.
Wenn ich die VM dann in der Test-VM normal starten will, kommt nach dem Auswahlbildschirm (ob normal oder Wiederherstellungsmodus) einfach ein Terminal-Bildschirm (der normal sowieso kommt) aber es passiert nichts mehr. Wenn ich den letzten Snapshot wiederherstellen will, kommt eine Meldung wie "Es konnte keine neue Sitzung erstellt werden" und irgend ein Fehlercode mit CPUID_MISMATCH darin. Genau kann ich es im Moment nicht sagen.
Das nächste Problem dabei ist, dass wenn die VM während dem Kopieren ausgeschaltet bleiben muss, der Server für eine relativ lange Zeit down ist. Im Moment ist die VM ca 50 GB groß. Das dauert natürlich etwas diese Menge zu kopieren.
Gibt es keine Möglichkeit einfach einen Snapshot zu erstellen und die das Backup dann im laufenden Zustand zu erstellen? Logisch wäre, dass das was nach dem Snapshot war im Backup fehlerhaft ist. Aber den Snapshot müsste man doch trotzdem wiederherstellen können.
Beitrag zuletzt geändert: 25.8.2013 22:55:09 von yorecords -
Vielleicht hilft es ja, wenn du uns sagst, welche Software du nutzt...Ah, im Titel versteckt. ;)
Ein Backup innerhalb der Vm, welches dann auf den Server geladen wird ist keine Möglichkeit?
Vielleicht hilft dir das weiter: http://www.howtogeek.com/howto/36870/how-to-backup-and-move-virtualbox-machines/
Ich hatte also Recht, nur braucht Virtualbox vor dem Kopiervorgang noch eine Spezialbehandlung. ;)
Beitrag zuletzt geändert: 26.8.2013 7:11:47 von tchab -
Hallo,
tchab schrieb:
Ein Backup innerhalb der Vm, welches dann auf den Server geladen wird ist keine Möglichkeit?
Theoretisch wäre es wohl möglich, wäre mir aber anders lieber..
tchab schrieb:
Vielleicht hilft es ja, wenn du uns sagst, welche Software du nutzt...Ah, im Titel versteckt. ;)
Vielleicht hilft dir das weiter: http://www.howtogeek.com/howto/36870/how-to-backup-and-move-virtualbox-machines/
Danke, das hab ich überhaupt noch nicht gesehen.. So könnte es funktionieren.
Hab aber gerade bemerkt, dass ich einen ganz anderen Fehler gemacht habe: Ich habe der VM, auf der das Backup dann getestet wird, ein paar für dieses Vorheben lebenswichtige Features (z.B. Intel VT-x/EPT) vorenthalten. Somit war VirtualBox von Anfang an nicht in der Lage, x64 VMs auszuführen. (Da hätte man ja wohl eine aussagekräftige Fehlermeldung einbauen können, anstatt es einfach nicht funktionieren zu lassen
)
Nachdem ich diesen Fehler behoben habe, kann ich jetzt ohne Probleme den ganzen Ordner kopieren und auf einem anderen PC starten (scheinbar werden die in dem Artikel aufgeführten Einträge mittlerweile automatisch von VirtualBox geändert).
Vielen Dank für deine Hilfe! -
Na ja, eigentlich sind die Backups in diesem Fall ja nur Kopien der virtuellen Festplatte. Insofern kannst du es auf jeder Architektur laufen lassen, die die selbe virtuelle Umgebung bietet. Da lassen sich dann auch Ausfälle durch Systeme mit anderem Host-System kompensieren. Ich bin zwar auch nicht so ein Fan von VM-Snapshots, muss aber zugeben, dass es sich dabei um eine sehr komfortable Lösung handelt. Meine Datenbanken sichere ich z.B. via SQL-Script regelmäßig auf einen Backup-Server, aber für meine Windows-Test-VM verwende ich auch Snapshots, da ich sonst jedes mal das System neu installieren müsste. Das wiederum ist in Anbetracht der beachtlichen Update-Anzahl eher unangenehm und lässt sich durch Snapshots leicht vermeiden.
Wie gesagt. Kommt auf den Typ der VM an, ob Snapshot oder Individual-Backup... Wobei die Individual-Lösung meist ohne Downtime auskommt. Zumindest bei meinen Datenbanken und Webservern...
Beitrag zuletzt geändert: 26.8.2013 23:42:22 von schrotti12 -
schrotti12 schrieb:
Na ja, eigentlich sind die Backups in diesem Fall ja nur Kopien der virtuellen Festplatte. Insofern kannst du es auf jeder Architektur laufen lassen, die die selbe virtuelle Umgebung bietet. Da lassen sich dann auch Ausfälle durch Systeme mit anderem Host-System kompensieren. Ich bin zwar auch nicht so ein Fan von VM-Snapshots, muss aber zugeben, dass es sich dabei um eine sehr komfortable Lösung handelt. Meine Datenbanken sichere ich z.B. via SQL-Script regelmäßig auf einen Backup-Server, aber für meine Windows-Test-VM verwende ich auch Snapshots, da ich sonst jedes mal das System neu installieren müsste. Das wiederum ist in Anbetracht der beachtlichen Update-Anzahl eher unangenehm und lässt sich durch Snapshots leicht vermeiden.
Wie gesagt. Kommt auf den Typ der VM an, ob Snapshot oder Individual-Backup... Wobei die Individual-Lösung meist ohne Downtime auskommt. Zumindest bei meinen Datenbanken und Webservern...
Wie meinst du das genau? Wie soll ich in dem Fall ohne Downtime auskommen? Wenn die VM nicht aus ist während ich sie kopiere, ist die Kopie zu nichts zu gebrauchen. Ich bin zwar seit ich meinen Fehler entdeckt habe noch nicht dazu gekommen viel auszuprobieren, aber glaube trotzdem nicht, dass mein anfänglicher Plan (Pause -> Snapshot -> Resume -> Kopieren -> beim Wiederherstellen einfach letzten Snapshot laden) funktioniert. Zumindest liest man überall dass das mit den Snapshots nicht funktioniert. Hast du soetwas schon realisiert?
Ich werd mich wahrscheinlich heut am Abend wieder dazusetzen, dann weiß ich genaueres. -
Na ja, auf meinem Datenbank-Server läuft ein Programm welches die Datenbank von SQL-Server zu SQL-Server kopiert. Sprich: Zur Laufzeit. Damit hab ich aber nur die Datenbank, nicht aber den Rest des Systems gesichert. Während des Vorgangs bleibt die Datenbank live und kann sich auch ändern. Das ist zwar ein Problem, welches aber von der DB-Engine abgefangen wird.
Hier findet die Sicherung auf Anwendungsebene statt wogegen sie bei Snapshots z.B. auf Dateisystem-Ebene stattfindet. -
schrotti12 schrieb:
Na ja, auf meinem Datenbank-Server läuft ein Programm welches die Datenbank von SQL-Server zu SQL-Server kopiert. Sprich: Zur Laufzeit. Damit hab ich aber nur die Datenbank, nicht aber den Rest des Systems gesichert. Während des Vorgangs bleibt die Datenbank live und kann sich auch ändern. Das ist zwar ein Problem, welches aber von der DB-Engine abgefangen wird.
Hier findet die Sicherung auf Anwendungsebene statt wogegen sie bei Snapshots z.B. auf Dateisystem-Ebene stattfindet.
Ah verstehe.
Bei mir lässt sich das so leider nicht realisieren. Auf meinem Server läuft Subversion, ein Wiki und ein Issue Tracker. Ich könnte die ganzen Daten natürlich trotzdem (etwas umständlich) auf einen anderen Server verschieben, aber hätte das Backup lieber lokal auf einer externen Festplatte. So kann ich bei einem Ausfall alles innerhalb weniger Minuten wiederherstellen.
Der Grund dafür, dass ich den Server überhaupt habe ist, dass ich diese Daten nicht unbedingt auf irgendwelchen fremden Server speichern will, bei denen ich keine Ahnung habe, wer darauf zugreifen kann. -
yorecords schrieb:
Ah verstehe.
Bei mir lässt sich das so leider nicht realisieren. Auf meinem Server läuft Subversion, ein Wiki und ein Issue Tracker. Ich könnte die ganzen Daten natürlich trotzdem (etwas umständlich) auf einen anderen Server verschieben, aber hätte das Backup lieber lokal auf einer externen Festplatte. So kann ich bei einem Ausfall alles innerhalb weniger Minuten wiederherstellen.
Der Grund dafür, dass ich den Server überhaupt habe ist, dass ich diese Daten nicht unbedingt auf irgendwelchen fremden Server speichern will, bei denen ich keine Ahnung habe, wer darauf zugreifen kann.
Ich vermute dass da Apache im Hintergrund läuft. Das sind ja von dem her nur Dateien auf der Festplatte, die du per tar zusammen packen und auf die externe Platte kopieren könntest. Das ganze in ein Shell-Script und dieses per Corn-Job ausgeführt und schon hast du deine Live-Sicherung. Zur Datenkonsitenz würde ich vom Backup-Script erst Apache und SVN beenden lassen, damit sich die Dateien während dem Packen nicht verändern. Zum Kopieren können die Dienste ja wieder laufen, da sich die Dateien ja im Archiv befinden.
Also sprich igendwie so
Das Script z.B. unter /usr/bin/backup.sh speichern.#!/bin/sh /etc/init.d/apache stop tar -pczf /tmp/backup.tar.gz /var/svn /var/www /etc/init.d/apache start mkdir /mnt/tmp mount /dev/sdb1 /mnt/tmp mv /tmp/backup.tar.gz /mnt/tmp/backup.tar.gz umount /dev/sdb1 rm -R /mnt/tmp
Die Zeile in /etc/crontab würde dann so aussehen:
Damit würde jeden Tag um 6:25 ein Backup durchgeführt. Kann natürlich sein, dass der Server dann, je nach Festplattenleistung und Dateigröße, ein paar Sekunden nicht erreichbar ist.25 6 * * * root /usr/bin/backup.sh
Und siehe da, schon landen die Backups auf der externen Festplatte. Könnte man ja noch Logik zur Erstellung von Unterordnern basierend auf dem Datum einbauen.
Beitrag zuletzt geändert: 28.8.2013 13:31:09 von schrotti12 -
schrotti12 schrieb:
Ich vermute dass da Apache im Hintergrund läuft. Das sind ja von dem her nur Dateien auf der Festplatte, die du per tar zusammen packen und auf die externe Platte kopieren könntest. Das ganze in ein Shell-Script und dieses per Corn-Job ausgeführt und schon hast du deine Live-Sicherung. Zur Datenkonsitenz würde ich vom Backup-Script erst Apache und SVN beenden lassen, damit sich die Dateien während dem Packen nicht verändern. Zum Kopieren können die Dienste ja wieder laufen, da sich die Dateien ja im Archiv befinden.
Also sprich igendwie so
Das Script z.B. unter /usr/bin/backup.sh speichern.#!/bin/sh /etc/init.d/apache stop tar -pczf /tmp/backup.tar.gz /var/svn /var/www /etc/init.d/apache start mkdir /mnt/tmp mount /dev/sdb1 /mnt/tmp mv /tmp/backup.tar.gz /mnt/tmp/backup.tar.gz umount /dev/sdb1 rm -R /mnt/tmp
Die Zeile in /etc/crontab würde dann so aussehen:
Damit würde jeden Tag um 6:25 ein Backup durchgeführt. Kann natürlich sein, dass der Server dann, je nach Festplattenleistung und Dateigröße, ein paar Sekunden nicht erreichbar ist.25 6 * * * root /usr/bin/backup.sh
Und siehe da, schon landen die Backups auf der externen Festplatte. Könnte man ja noch Logik zur Erstellung von Unterordnern basierend auf dem Datum einbauen.
Vielen Dank für deine Hilfe!
Du hast Recht, das währe wirklich eine gute Lösung. Aber leider ist auch das nicht ganz so einfach bzw. für meine Zwecke nicht ausreichend. Zumal häte ich gerne ein komplettes Backup (inkl. aller System-EInstellungen), damit ich im Falle eines Ausfalles alles innerhalb weniger Minuten wieder genau so herstellen kann wie es war. Des Weiteren ist es leider (zumindest im Moment) nicht möglich, eine externe Festplatte die ganze Zeit am Server zu haben. Diese Festplatte steckt am Host und wird dort auch benötigt, und zumindest im Moment ist es mir nicht möglich eine weitere anzuschaffen (was wegen fehlender Steckplätze auch alleine keinen SInn hätte).
Mittlerweile habe ich aber mehrer Threads gefunden die besagen, dass es scheinbar kein Problem ist eine virtuelle Festplatte (zumindest im VDI-Format) zu verschieben. VHDs haben leider Header und Footer, die sehr Fehleranfällig sind. Ich müsste also im Prinzip nur die vorhandene VHD in eine VDI konvertieren (hoffe es funktioniert mit allen Daten ohne Probleme), dann sollte es an sich funktionieren. Zwar müsste ich den Server dazu auch kurz ausschalten, aber wenn ich in dieser Zeit einfach schnell eine temporäre Kopie der VDI mache und die erst anschließend packe, sollte es nicht länger als ein paar Minuten dauern. Leider müsste ich mich bei dieser Lösung auch von allen Snapshots trennen, aber ich behalte einfach eine Kopie der jetzigen VM, somit sind die auch nicht verloren.
Jetzt muss ich nur noch rausfinden wie ich das Ausschalten über ACPI-Event in Debian zum Funktionieren bringe... -
Ist auch eine Lösung und wenn sie für dich funktioniert ist sie auf jeden Fall brauchbar.
Ich will trotzdem das Thema noch kurz weiter führen:
Das Tolle an Linux ist: Es lassen sich auch Samba-Freigaben, FTP-Server, etc. etc. ins Dateisystem mounten
Dann erfolgt die Sicherung nicht einmal mehr auf dem Rechner und deine Downtime minimiert sich, da der Server während dem eigentlichen Upload auf den Sicherungs-Server schon wieder arbeitet.
Zu deinem Punkt mit der Vollsicherung zwecks Wiederherstellung: Ich habe Apache2 und Subversion (1.8.1) ins Verzeichnis "/opt" kompiliert und installiert. Ansonsten befinden sich im System nur noch die Init-Scripts welche ich in den Backup-Prozess integrieren kann.
Sprich: Bei mir müsste ich die Verzeichnisse "/opt", "/etc/init.d" und "/var/svn" sichern.
Natürlich: Um eine Neuinstallation des Systems komme ich nicht herum, aber wenn das System ausfällt (Festplatten-Fehler, Angriff, Fehlinstallation) mache ich persönlich eh lieber eine Neuinstallation. V.a. kann ich ein personalisiertes Restore-Script schreiben, welches den Server mountet, die letzte Datei zurück spielt und alles wiederherstellt...
Ich will dich auf keinen Fall von deiner Lösung abbringen, biete aber gerne Ideen an, die sich vlt. für ähnliche Fälle besser eigenen.
Wenn dich derartige Installations-Routinen interessieren, habe ich vor geraumer Zeit diese Seite zusammengestellt: http://s4.schrotti12.eu/scenarios/subversion-server-with-ldap-authentication Einfach das Script runterladen, entpacken und analysieren. Kann nach Belieben umgebaut werden. Evtl. müssen die Packages auf den Servern auf neue Versionen überprüft und gegebenfalls im Script aktualisiert werden.
Beitrag zuletzt geändert: 29.8.2013 14:49:36 von schrotti12 -
schrotti12 schrieb:
Ist auch eine Lösung und wenn sie für dich funktioniert ist sie auf jeden Fall brauchbar.
Ich will trotzdem das Thema noch kurz weiter führen:
Das Tolle an Linux ist: Es lassen sich auch Samba-Freigaben, FTP-Server, etc. etc. ins Dateisystem mounten Dann erfolgt die Sicherung nicht einmal mehr auf dem Rechner und deine Downtime minimiert sich, da der Server während dem eigentlichen Upload auf den Sicherungs-Server schon wieder arbeitet.
Zu deinem Punkt mit der Vollsicherung zwecks Wiederherstellung: Ich habe Apache2 und Subversion (1.8.1) ins Verzeichnis "/opt" kompiliert und installiert. Ansonsten befinden sich im System nur noch die Init-Scripts welche ich in den Backup-Prozess integrieren kann.
Sprich: Bei mir müsste ich die Verzeichnisse "/opt", "/etc/init.d" und "/var/svn" sichern.
Natürlich: Um eine Neuinstallation des Systems komme ich nicht herum, aber wenn das System ausfällt (Festplatten-Fehler, Angriff, Fehlinstallation) mache ich persönlich eh lieber eine Neuinstallation. V.a. kann ich ein personalisiertes Restore-Script schreiben, welches den Server mountet, die letzte Datei zurück spielt und alles wiederherstellt...
Ich will dich auf keinen Fall von deiner Lösung abbringen, biete aber gerne Ideen an, die sich vlt. für ähnliche Fälle besser eigenen.
Wenn dich derartige Installations-Routinen interessieren, habe ich vor geraumer Zeit diese Seite zusammengestellt: http://s4.schrotti12.eu/scenarios/subversion-server-with-ldap-authentication Einfach das Script runterladen, entpacken und analysieren. Kann nach Belieben umgebaut werden. Evtl. müssen die Packages auf den Servern auf neue Versionen überprüft und gegebenfalls im Script aktualisiert werden.
Schaut interessant aus, danke. Bei Gelegenheit wird ich mal alles umstellen, aber im Moment sollte das reichen.
Da ich noch nicht allzu lange mit Linux zu tun habe, hab ich bei den Installationen auch nicht darauf geachtet eine gewisse Struktur zu erstellen, sondern einfach alles installiert (wo es halt gerade hin will). Das muss ich bei Gelegenheit sowieso noch ändern. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
