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.
The final 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 http://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, but cannot have sub-directories.
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.
If your system hosts virtual servers that contain a large amount of content in their home directories which does not change often (such as images, PDFs or video files), backing them up daily will be both slow and wasteful. Almost all the contents of each backup will be identical to the previous run, so most of the data transferred is not really necessary.
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.
If you have enough disk space, keeping backups made over several days or months is a good idea, as it allows you to return virtual servers to their state before some disaster occurred, which may not have been immediately noticed. The standard way to do this in Virtualmin is to use a backup path that contains special tokens that vary based on the current date and time.
For example, the path
/backup/%d-%m-%Y would be converted to
/backup/16-09-2008 on 16th Semptember 2008. All tokens supported by the Unix
strftime function can be used in backup paths, but the most useful are :
%d- Day of the month, padded to 2 digits
%m- Month of the year, padded to 2 digits
%Y- Year, as a 4 digit number
%H- Hour of the day, padded to 2 digits
%M- Minute of the hour, 2 digits
%a- The short weekday name, like
To use these tokens in backup paths, you must check both the Do strftime-style time substitutions on file or directory name and Create destination directory boxes on the backup form.
The only problem with keeping old backups around using date-based paths is the amount of disk space consumed. However, removing those older than some number of days is relatively easy to setup in Virtualmin. When creating or editing a scheduled backup, use the Delete old backups field to enter a maximum age in days before backups are removed.
This can only be used if your backup path contains date substitution tokens, like
/backup/virtualmin-%d-%m-%Y. If not, Virtualmin will not be able to work out which files and directories are backups that it made in order to safely delete them.
In addition, I recommend against using the same directory to store backups made using other programs, as if their filenames are similar to Virtualmin backups they may be deleted as well if too old.
If you have more than one system running Virtualmin, backups and restores can be used to transfer domains between them easily. The restore process will even re-create the virtual servers on the target system, and adjust the backups to match the target's mailbox format, mail server, home directory base and other system-specific settings.
The steps to transfer a virtual server between systems are :
Create a backup on the source system containg the top-level server you want to transfer, and all sub-servers. The Include sub-servers checkbox on the backup form makes this easy.
Copy the backup file(s) across to the target system, if they weren't already transferred directly as part of the backup process.
Use the restore form to re-create the domains from the backup files. If you select them all at once, any top-level servers will be restored before sub-servers, and their heirarchy correctly preserved.
Update DNS entries or change nameservers at your registrar so that they new system serves the domains.
Verify that everything is working on the new system, paying particular attention to PHP applications that may have un-expected dependencies on the old system.
Delete the virtual servers from the source system.
While every effort is made in Virtualmin to convert backups as necessary when restoring on a system with a different configuration to the original, in some cases this cannot be done 100% correctly. For example, if the new system uses a different base for home directories (like
/virtualmin instead of
/home), paths in PHP, Python or Ruby application configuration files may no longer be correct.
For this reason, I recommend moving domains between systems running identical operating systems where possible, such as CentOS 5.2. However, the underlying CPU architecture, disk partitioning scheme or amount of RAM does not matter, so it is perfectly save to move domains between old and new hardware running the same OS.
In addition to virtual servers, backups made by the master administrator can also contain Virtualmin settings that apply to the whole system, such as templates and custom fields. If you have created your own templates or heavily customized the module configuration, you should back these settings up too as follows :
Create a new scheduled backup, as described above.
In the Servers to save, choose the Only selected option but do not select any domains.
Under Features and settings, check all the boxes in the Virtualmin settings to also backup section. Or if you only want to save some global settings, just check the ones you want.
Select a backup destination as normal. This can either be a single
tar.gzfile which will contain all the global settings, or a directory. In the latter case, a file named
virtualmin.tar.gzwill be created in the target directory to store the global configuration backup.
Select a schedule, and click the Create Schedule button.
It is also possible to include global Virtualmin settings in your backups of virtual servers, by selecting the ones to include in the Virtualmin settings to also backup field.
The various global Virtualmin configuration settings can be restored in exactly the same way as you would restore domains. Just select the
virtualmin.tar.gz file as the source to restore from, and in the Virtualmin settings to restore section check the types of global settings to include.
This can even be used to migrate templates, custom fields, script installers, content styles , resellers and email messages to a new system. Be careful when migrating the Module configuration though, as it may not be compatible with the new system if running a different operating system or Linux distribution. Instead, it is safer to configure the target the way you want it, then restore domains and possibly other global settings.
If you prefer to work at the command line, backups and restores can be done using the tools listed on the Backup and Restore API page. These allow you to create your own scripts for backing up on complex schedules, emailing backups to somewhere, using rsync to transfer home directory contents, or whatever you can come up with.
Here's what we do at Virtualmin.com:
Weekly full backup, and daily incremental backup, using the Webmin:System:Filesystem Backup module. This insures we have a copy of everything on the system, in the event of a problem. Keep in mind that this is a filesystem dump, using the
dump command by default (though tar is also an option), so it won't jump file systems. If you have multiple partitions, you'll need to make a backup of each. It takes two scheduled backups to get weekly full and daily incremental backups.
Daily backups of all virtual servers on the system using Virtualmin's Backup feature. We do a full backup, including Virtualmin meta-data and Webmin stuff, but if the data will be moving over a slow pipe, you may consider using the incremental backup feature.
If we had a problem that required a restoration, here's what I'd do, assuming it is one of my remote systems, rather than in a local data center:
Get a new system running whatever OS I had before (though I might be tempted to upgrade during the process...I'd have to assume that would take longer to get back in service).
Restore the virtual server backups from the Virtualmin backups. Test. If something is broken (because of customizations I did outside of Virtualmin to non-Virtualmin related services), install the necessary packages (assuming I installed everything from packages, as I generally do), and restore the configuration (if necessary) by selectively pulling stuff out of the filesystem dump...or creating a whole new filesystem and restoring the dump completely into it, if I thought I'd be doing a lot of this (since restoring single files from a dump is somewhat time-consuming).
If it were a local system, and I'd replaced the disk, or something, I would do something pretty dramatically different:
Boot from a rescue disk for the OS in question (don't go newer, as you might get slightly incompatible Ext3 filesystem versions--Fedora, in particular, makes use of new attributes that confuse older kernels).
Create the necessary filesystems (swap and /, probably, though you might also have /home), and restore the dump directly into /. This will completely restore your machine exactly as it was before the catastrophe. This is probably faster than the above method--unless you happen to have a machine laying around with a fresh OS install of exactly the right kind and version you can start with--and will get you a system identical to the previous one.
There is one quirk to be aware of in this latter case:
Backups of databases in a dumped filesystem are almost certainly not trustworthy, unless you shut down your database during the dump. So, you'll still need to plan to restore databases from the dumps found in your Virtualmin backups, which use the database dump feature to dump a safe and sane text file that can reproduce the database exactly as it was at the time of the backup.
Obviously, you want to test your backups occasionally to be sure they are working correctly and can be restored.