How to backup VirtualBox virtual server?

Paraphrased from John's answer, "Treat the virtual as you would a physical machine". Any software/method to backup while running will work. You may also want a backup of the virtual machine's configuration file (.vbox) if the backup method doesn't already include it. Most bare-metal backups are done without the standard system running. Most incremental/differential data backups can be performed with the system running.

Be aware that the "VBoxManage clonehd" (clonevdi is deprecated) will change the UUID. Many current Linux distributions use UUID's for mounting and you will need to modify the UUID or /etc/fstab to get the cloned disk to boot.

Also clonehd does not copy the machine, only the disk. You may have specific virtual system settings necessary for correct running of the virtual, multiple NICs, large memory setting, etc..

Try to use multiple disks to separate system from data to reduce the down time for clone or backup. If the virtual is a web server, use a separate disk for www-root where most daily changes will be made. No need to repeatedly backup the system disk unless programs or config files are updated. Don't forget to backup the logs if you need them.

Also look into using VirtuaBox immutable disks after initial virtual install and setup. The immutable system disk can be shared among many virtual machines. It is read-only and only needs to be backed up once, or whatever retention number you feel safe with, usually three or four copies is sufficient. Only the differencing disks will need to be backed up regularly.

Most of our virtual servers are pre-backed up by virtue of source revision control. All changes to the virtual machine configuration files (.vbox), the virtual's etc config files and virtual data are published through source control which is backed up externally. A rebuild/restore consists of checking out the vbox machine file, booting up the virtual machine against the immutable and reloading the difference disk from source control to a checkpoint or branch tag. This works well for services servers.

Virtual client test machines (different versions of windows) usually are too cumbersome for this method and need export/import, clonehd or clonezilla type backups.

Clonezilla bare-metal backup/restore - boot virtual to clonezilla iso and an extra attached backup data disk or use shared folders for the backup destination. This backs up and compresses in one pass. Clonehd and export will need space for up to three copies temporarily during the backup if you also compress after the clonehd operation. After backup or restore remove clonezilla iso mount, extra backup disk or share folders and restart system. Restore is the same procedure as backup.

If you use any method other that export/import you may need to fiddle the UUIDs in the virtual machine config (.vbox) file or within the virtuals /etc/fstab (sometimes even with export/import for /etc/fstab) to get things working after a restore/rebuild.

Export and import is the brain-dead method. Export will copy both machine settings and disk. It will take a long time and use nearly double the virtual's disk space. The virtual should not be running during export or import.

If you want the absolute minimal downtime for your virtuals and minimal data transfer for incremental backups, look at using openIndiana (Solaris) or variants running ZFS as a virtual host system. Easy snapshot, replication and de-duplication. Clean snapshots of virtuals take less time than the shutdown/restart sequence on the virtual. The shutdown ensures database integrity, if running SQL databases and enforces lock-out/no changes are made during backup. After the shutdown/snapshot/restart sequence is completed, usually less than a few minutes, the virtual is running/usable. Then use ZFS sync to transfer only the snapshot changes to another backup machine or external disk at your leisure.

Copy .vdi file in the HardDisks directory to the safe place. (you can use VBoxManage clonevdi ...).

You can either export the VM, which can them be imported into the same or another host, or you can use regular backup tools, just as you would with a physical host. There is no real reason to treat a VM any differently to a physical machine for backup purposes.