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 root or 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 /home directory.

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 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, 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 http://www.rackspace.com/cloud/public/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 :

1. Login to Virtualmin as the master administrator, typically root
2. Open the Backup and Restore category on the left menu, and click on Scheduled Backups
3. Click on the Add a new backup schedule link to open the backup creation form.
4. From the Servers to save menu, choose the domains that you want to backup. Selecting them all is generally the best bet.
5. In the Features and settings section, make sure Backup all features is selected.
6. 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.
7. 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.
8. In the Schedule and reporting section, enter your email address in the Email backup report to field.
9. Unless you want to get email every time a backup is done, check the Only send email on failure box.
10. 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.
11. 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 :

1. Open the Backup and Restore category on the left menu, and click on Restore Backup
2. 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 /backup/example.com.tar.gz
3. 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.
4. 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 Sat

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 :

1. 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.
2. Copy the backup file(s) across to the target system, if they weren't already transferred directly as part of the backup process.
3. 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.
4. Update DNS entries or change nameservers at your registrar so that they new system serves the domains.
5. 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.
6. Delete the virtual servers from the source system.

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 :

1. Create a new scheduled backup, as described above.
2. In the Servers to save, choose the Only selected option but do not select any domains.
3. 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.
4. Select a backup destination as normal. This can either be a single tar.gz file which will contain all the global settings, or a directory. In the latter case, a file named virtualmin.tar.gz will be created in the target directory to store the global configuration backup.
5. 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).

Install Virtualmin.

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.

Virtualmin Pro versions 3.92 and later support the encryption and signing of backups with GPG keys. This can be used to protect the contents of a sensitive backup from prying eyes or modification if stored on an un-trusted remote system, such as S3 or an FTP server managed by another company.

Before a backup can be encrypted, you must create or import at least one key at Backup and Restore -> Backup Encryption Keys. A key can either be generated by Virtualmin, or imported from an existing GPG secret key file in ASCII format.

Once a key has been created, it can be selected on the one-time or scheduled backup form using the Encrypt backup with key field. When the backup is restored, the same key must also be selected using the field with the same name on the restore form.

WARNING - If a backup key is lost, any backups made using it will not be recoverable! For this reason, you should save the ASCII format key text separately. This can be found on the Backup Encryption Keys page, by clicking on a key. This way if your Virtualmin system fails and you need to restore backups onto a new system, the key can be imported first.

Virtualmin has several account-related configuration settings that apply to all backups, which can be set by the root user at Backup and Restore -> Cloud Storage Providers -> Amazon S3 . They are :

• S3-compatible server hostname
  
  Other services that provide an API compatible with Amazon S3 exist, and can be used by entering the URL of the API endpoint here. This will apply to all S3 backups.
  
• Default S3 login
  
  This can be used to set the default login and password for S3, so that you don't have to enter them for each scheduled or manual backup. They are also used by the S3 API and shell commands if no keys are specified.
  

For backups to Rackspace, you can edit global settings at Backup and Restore -> Cloud Storage Providers -> Rackspace Cloud Files :

• Rackspace API URL
  
  By default Virtualmin uses the US Rackspace Cloud Files endpoint, but if you have created an account with Rackspace UK you will need to change this field to use their UK service. This applies to all backups.
  
• Rackspace username
  
  This can be used to set the default login and password for Rackspace Cloud Files, so that you don't have to enter them for each scheduled or manual backup. They are also used by the Rackspace API and shell commands if no keys are specified.
  

Virtualmin versions 4.01 and later can manage S3 bucket settings, such as access control lists and lifecycle policies.
This can be used to grant access to backups to other users of S3, to setup automatic deletion of backups, and to have files moved to Amazon's long-term storage service called Glacier.

Buckets owned by S3 accounts used for Virtualmin backups can be accessed at Backup and Restore -> Amazon S3 Buckets. To edit the settings for an existing bucket, just click on its name. Or use the link above the list to create a new empty bucket. When editing a bucket you can enter one or more access control rules that grant permissions to other S3 users, identified by their email addresses.

Lifecycle rules can also be created for a bucket, which control what happens to some or all files either on a specific date, or some number of days after they were uploaded. For each rule you can set a filename prefix it applies to, and choose when files will be moved to Glacier or deleted. Currently there is no support in Virtualmin for restoring files from Glacier - this is a multi-hour process that must be perform using Amazon's S3 management console.

If you have an account with Google Cloud Storage and have created a project, you can use it for Virtualmin backups. The first step is to connect your GCS account to Virtualmin, as follows :

1. Login to the Developers Console at https://console.developers.google.com/project. Make a note of the Project ID (which is different from the project name).
2. Click on APIs and auth, and then on Credentials. From the Add credentials menu, select OAuth2 Client ID.
3. Select Other, and then click Create. A client ID and client secret will then be displayed - keep the window open, as you will need them in Virtualmin.
4. Login to Virtualmin as root, and go to Backup and Restore -> Cloud Storage Providers -> Google Cloud Storage. Fill in all the fields using the details from Google's developer console as obtained above, then click the Save button.
5. Click the link to begin the OAuth2 enrollment process - this should open a separate tab in which you tell Google that Virtualmin is authorized to access your GCS files. Once you have confirmed, a code will be displayed that must be entered into Virtualmin in the original tab.

And that's it - you can now select Google Cloud Storage as a backup destination in Virtualmin.