27.6.2.2 The ArchivistaVM concept
Things can be a lot simpler than the process described above. The host (virtualisation software) and the guest (virtualised operating system) operate autonomously, the guest is briefly shut down during data backup, data backup is executed and the guest is rebooted. If the guests are redundant on the hard drive, the time during which the guest is unavailable can be extremely short. Guest shutdown, 2nd hard drive unmounted, guest booted, backup executed, 2nd hard drive re-mounted.
If no guest shutdown is carried out (in the Linux environment this is generally frowned upon, long uptimes are the pride of any administrator), the relevant scripts in ArchivistaVM can be started outside the guest before and after data backup, which thereby ensures that the data in the guest is in a static condition. But if we're being honest, even Linux operating systems are nowadays much more readily updated than they were previously, and here too it is becoming increasingly desirable to backup the entire guest, so as not to be in the position of having the wrong version of the database server when retrieving on some future 'Day X'.
The concept used by ArchivistaVM is sadly not used for virtualisation solutions, although instances are 100% static and autonomous only in this concept. The concept needs no additional data backup software, as many instances as required can be backed up retrospectively and there is no guest-dependency - in a nutshell, these are standard compliant hard drive files which, if necessary, can be booted or opened offline.
Note: Just to make sure that we all completely understand each other, ArchivistaVM can, of course, implement trouble-free hot-swap backups in the qcow2 format, but these backups contain precisely the same defects as the other solutions, so we won't highlight these further!