Virtualmin Backup Restore Testing: Single Archive vs Server Backups

Virtualmin Backups Tested: Single Archive vs One File Per Server Restore

Backups are easy to create. The real test is whether they can actually be restored when you need them.

While setting up Virtualmin scheduled backups, I decided to go beyond simply checking that the backup job completed successfully. I wanted to test the full recovery process by restoring a backup onto a completely different Virtualmin installation.

During the testing, I found an important difference between the two Virtualmin backup formats:

Single archive file
One file per server

Both are valid backup methods, but the restore process is different, and this is something that is not immediately obvious from the Virtualmin interface.

Why am i testing virtualmin restores

A successful backup message is useful, but it does not prove you have a recoverable backup.

A backup can fail to restore because of:

incorrect backup settings
missing files
incorrect permissions
incomplete transfers
misunderstanding how the restore process works

The only way to know a backup works is to actually restore it.

For this test, the goal was:

Create a scheduled Virtualmin backup on my dedicated backup server (large storage space allowed)
Connect and store it remotely using SFTP vs FTP.
Connect my failover Virtualmin server to the the backup server using SFTP.
Restore and verify the backup contents.

Virtualmin backup test setup

The backup was configured as a scheduled Virtualmin backup and stored remotely using SFTP.

The backup destination used a date-based filename:

mytestbackup-%Y-%m-%d.tar.gz

This resulted in a backup file similar to:

mytestbackup-2026-07-10.tar.gz

Using date-based filenames has another advantage: it allows Virtualmin to identify older backups for automatic cleanup.

If you want to keep multiple backups and keep them for x days, Virtualmin can then remove x days old backups.

Single archive file backup

The first backup format tested was:

Single archive file

I created the folders on my backup server to receive the file.

e.g.

/BACKUP/DOMAIN/DAILY/

In setting up the configuration for the schedule on the host website which I want to backup:

File on server =

/BACKUP/DOMAIN/DAILY/mytestbackup-%Y-%m-%d.tar.gz

This creates one main backup archive containing the virtual server data.

Example:

/BACKUP/DOMAIN/DAILY/mytestbackup-2026-07-10.tar.gz

For scheduled backups, this format is convenient because the backup is a single portable file.

This saves you having to download the file to a PC then upload again, saving time and bandwidth.

When restoring, Virtualmin expects the actual backup archive file.

The restore test was performed from my Virtualmin Failover installation.

In the restore source, enter the SFTP details of your storage server.

Critical: enter the actual backup filename, for example:

mytestbackup-2026-07-10.tar.gz

The result:

Checking contents of the backup ..
.. found 1 virtual servers and 7 global Virtualmin settings

This confirmed that Virtualmin could read the archive and identify the virtual server successfully.

The backup was not just created — it was proven recoverable.

One file per server backup

The second format tested was:

One file per server

This creates separate backup files for each virtual server.

A typical backup set looks like:

mydomain.tar.gz
mydomain.dom
mydomain.info

When you set up destination SFTP details, this differs.

File on server =

BACKUP/DOMAIN/DAILY/

(do not enter a filename here)

Restoring using the SFTP source again:

BACKUP/DOMAIN/DAILY/

is enough.

Important: I have not tested this, but I think the idea is if you backup, let's say, 100 domains and you want to restore 100 domains, you need to find the best way for you.

It really is an individual thing, and you need to test restores and document what you did in the event of a recovery-needed situation.

My backup approach and lessons learned

While testing scheduled backups and restoring them, it reinforced an important point:

Setting up a backup schedule is only the first step. You also need a recovery plan.

My approach is not to rely on a single backup method.

For individual websites, I prefer creating separate virtual server backups. This makes it easier to restore one website without having to restore an entire server backup.

I also run a separate database-only backup covering all servers and send this to a secure remote location using SFTP.

Database backups are especially important because databases often contain the most frequently changing information.

For busy eCommerce websites, where orders, customer information and stock levels can change throughout the day, a higher-frequency database backup schedule can be a very useful addition.

A few backup practices I would recommend:

Do not keep backups only on the same server you are protecting.
Use a secure remote backup location such as SFTP.
Regularly change the SFTP user password used for backup access.
Keep manual backups as an additional safety net.
Take manual backups before major changes, migrations or updates.
Test restores regularly.

A backup that has never been restored is only a theory.

Conclusion

If you have clients willing to invest their trust in your service, it's surely has to be worth taking the time to practice, practice, practice in case something awful happens.

I always like per domain / virtual server backups, I assume that a website could be hacked or break at any minute and would like an immediate solution for the client. This then assures trust to you and will help you get recommended from your clients.

Found This Useful?

If you found this useful, please consider sharing it.

WEB WORKBENCH