Virtualmin provides multiple tools to help you keep good backups automatically. The first step after any installation of Virtualmin should probably be thinking about your backup procedures and setting up Virtualmin to automate those procedures for you.
The simplest way to backup your virtual servers is to use the backup feature built into the Virtualmin UI, which can save them to local or remote files domain by domain. This allows you to restore the state of an entire virtual server (including all databases, users and aliases), without effecting other parts of the system.
Each virtual server's backup is typically a single file in
tar.gz format. This contains one or more files per Virtualmin feature that is included in the backup, such as the contents of databases, DNS records, Apache directives or the virtual server's home directory. It is also possible for a single backup file to contain multiple servers, although this format is generally not as easy to work with.
By default, only the master administrator (typically
admin) can perform backups, but it is possible to grant backup and restore rights to resellers and domain owners too. Only the master admin can restore all virtual server settings though, as some (such as the Apache configuration) could harm other system functions if a corrupt or malicious backup was restored.
Before you can backup anything, you need to decide where your backups are going to be stored. The simplest destination is a directory on the system running Virtualmin, such as
/backup, but clearly this isn't going to be useful if the whole system dies. If you do want to backup to local files, at least make sure they are on a different hard drive than the home containing your
A better alternative is to backup to another system, perhaps owned by your or maybe provided by your colocation company. The backup files can be transferred either via FTP or SSH, depending on which protocol the destination system supports. Almost all Unix systems will allow SSH logins, but some network attached storage devices will only support FTP.
Another option is to use Amazon's S3 storage service, which charges you by the megabyte for data stored on their systems. This is probably the safest option as S3 presumably uses RAID and has backups of their own, but is more costly and slower to transfer backups to over the Internet. For more information about signing up for S3, see https://aws.amazon.com/s3 .
S3 uses slightly odd terminology to refer to files that they store - instead of directories, they have 'buckets', whose names must be unique across all S3 users. A backup can contain multiple files, such as individual domain backups, and backups can be placed into sub-directories under buckets.
Alternately, you can backup to Rackspace's Cloud Files service. This is similar to S3, in that your backups are saved to storage managed by another company. For more info, see https://docs.rackspace.com/support/how-to/cloud-files. Rackspace uses the term 'container' to refer to a directory, which only needs to be unique for each user. Containers can contain multiple backup files and sub-directories. If you have an account with Rackspace UK, make sure Virtualmin is configured to use the UK API endpoint, as documented below.
The best way to have your system backed up is to have Virtualmin do it automatically on a regular schedule, such as once per day. The steps to set this up are :
Login to Virtualmin as the master administrator, typically
Open the Backup and Restore category on the left menu, and click on Scheduled Backups
Click on the Add a new backup schedule link to open the backup creation form.
From the Servers to save menu, choose the domains that you want to backup. Selecting them all is generally the best bet.
In the Features and settings section, make sure Backup all features is selected.
In the Backup destination box, choose if you want to backup to a local file or a remote SSH or FTP server. For remote systems, you must enter the login details for the destination system.
If you want to save each domain to a separate file (recommended), the destination path must be an existing directory like
/backup. For the Backup format, select One file per server.
In the Schedule and reporting section, enter your email address in the Email backup report to field.
Unless you want to get email every time a backup is done, check the Only send email on failure box.
In the Scheduled backup time section, select a schedule. I would recommend just choosing Daily (at midnight), but more complex times and dates can be chosen with the Complex schedule option.
Click the Create Schedule button.
Once this is done, your virtual servers will be safely backed up every night. To force an immediate backup for testing purposes, go to the Scheduled Backups page and click on the Backup link next to your new schedule.
Sometimes you just want to backup a few virtual servers to a different destination a single time, rather than one a regular schedule. To do this, click on the Backup Virtual Servers link on the left menu, and fill in the backup form as described above. When you click the Backup Now button then selected domains will be immediately backed up, and their progress displayed in your browser.
If a virtual server has been accidentally deleted, or lost files, database content or users, you can restore some or all of it's data from a backup. In the case where the whole domain is gone, Virtualmin will re-create it for you as part of the restore process.
The steps to restore a domain are :
Open the Backup and Restore category on the left menu, and click on Restore Backup
In the Restore source section, enter the local or remote path to restore from. If you are just restoring one server, it is best to enter the full path to it's backup file, like
Under Features and settings, you can control if all attributes of the virtual server are restored (overwriting any that it currently has), or just some. For example, if you wanted to restore just the domain's databases, you could select Only those selected below and then check the box next to the MySQL feature. By default, everything will be restored.
Click the Show What Will Be Restored button at the bottom of the page.
After this step, the backup will be downloaded from it's source FTP or SSH server and a confirmation page displayed showing which domains and features will be restored. Be careful when restoring existing domains, as any aliases, databases or mailboxes that they have will be removed and replaced with those in the backup.
If everything looks OK, click the Restore Now to begin the restore process. As it runs, the progress of each domain and feature will be displayed by Virtualmin.
Individual virtual server owners can backup their own top-level domains and sub-servers, if granted permission on the Edit Owner Limits page in the Allowed capabilities and features section. They can even be given the rights to run scheduled backups, although that right should not be granted to users you don't trust not to abuse it, as a large number of scheduled backups could overwhelm the system.
The UI for server owner backups is almost identical to that for the master administrator, with the exception that local backups can only be made to the
.virtualmin-backup directory under their top-level server's home directory. There are no limits on remote FTP, SSH and S3 backups though.
When allowed, restored by domain owners are even more limited - to prevent configuration file corruption or hacking attempts by corrupt backups, only home directory and database contents can be restored. And local restores can only be from the
.virtualmin-backup directory, not any file on the system.
Fortunately, Virtualmin has a solution - incremental backups. These contain only files that have changed or been added since the last full (non-incremental) backup, and are thus much faster. Typically you should schedule a full backup for once a week, and an incremental backup for the same domains every night - but to a different directory.
Enabling incremental mode for a scheduled backup is as simple as changing the Backup level option to Incremental. This will only apply to home directory contents - Virtualmin does not support detection of incremental changes to databases, so if your virtual servers have a large amount of data in MySQL, the saving will probably be minimal.
When restoring, the latest full backup must be restored first, followed by the latest incremental. This ensures that all files are returned to their state at the time the incremental backup was made.