Dabei könnte das Leben viel einfacher sein. Der Gastgeber (Sofware für Virtualisierung) und der Gast (virualisiertes Betreibssystem) arbeiten für sich autonom, bei den Datensicherungen wird der Gast kurz heruntergefahren, die Datensicherung durchgeführt, und anschliessend wir der Gast wieder hochgefahren. Liegen die Gäste auf den Festplatten redundant vor, so kann die Zeit, in der der Gast nicht zur Verfügung steht, äussert kurz gehalten werden. Gast herunterfahren, 2. Festplatte aushängen, Gast hochfahren, Sicherung durchführen, 2. Festplatte wieder einhängen.
Wo das Herunterfahren des Gastes nicht passt (im Linux-Umfeld ist dies mitunter verpönt, lange Uptimes sind der Stolz jedes Admins), so können bei ArchivistaVM entsprechende Skripte vor und nach der Datensicherung ausserhalb des Gastes gestartet werden, die zuverlässig dafür sorgen, dass die Daten im Gast in einem statischen Zustand vorliegen. Aber seien wir ehrlich, auch Linux-Betriebssysteme werden heute deutich zeitnaher aktualisiert als früher, auch hier wird es zunehmend wünschenswert, immer den gesamten Gast zu sichern, um am Tag-X bei einem Rückspielen nicht doch die falsche Version des Datenbankservers vorliegen zu haben.
Das von ArchivistaVM verwendete Konzept wird leider bei Lösungen zur Virtualisierung nicht verwendet, obwohl nur bei diesem Konzept die Instanzen zu 100% statisch und autonom vorliegen. Das Konzept benötigt keine zusätzliche Software zur Datensicherung, es können rückwirkend beliebig viele Instanzen gesichert werden, es besteht keine Abhänigkeit zu den Gästen, kurz und gut, es liegen standardkonforme Festplatten-Dateien vor, die wenn es sein muss, jederzeit hochgefahren oder auch offline geöffnet werden können.
Hinweis: Damit wir uns richtig verstehen, ArchivistaVM kann im qcow2-Format HotSwap-Sicherungen selbstverständlich problemlos durchführen, nur enthalten diese Sicherungen die gleichen Mängel wie dies bei anderen Lösungen der Fall ist, und daher werden diese nachfolgend auch nicht weiter vorgestellt!.