A important part of any site is the backup. My VPS is on Digital Ocean so I have the option to take an image (or images) or to pay a bit extra and have regular backups. However, neither or these is diverse from Digital Ocean so if the company suddenly stopped trading I would be without a backup. But it is the easiest method so it is worth at least saving some images as it is very quick to restore an image.

1. Virtualmin Backup/Restore

Virtualmin has a good backup/restore as long as some rules are followed. These rules are:

• Database users must be Virtualmin users and not Webmin users.
• Database password must be set in Virtualmin and not Webmin.
• Databases must be created under Virtualmin and not Webmin.
• Cron users must be Virtualmin users, not Webmin or Linux users.

To explain, under Webmin, Servers->MySQL Database Server you can create databases and users of databases but Vitualmin doesn't know about these users and so does not back them up. The correct method for creating a database is Virtualmin, Select Virtual Server, Edit databases. In the same place, clicking Passwords will show the primary user and password or change the password. Virtualmin saves this in a file so it can restore the databases and users. A Virtualmin restore doesn't just replace files, it rebuilds the site. Hence it needs the passwords and it needs to know the user. This is why it does not restore any database users created under Webmin. Similarly cron tasks are only backed up and restored by Virtualmin if their user is one of Virtualmin users and not say the Linux user nobody.

Unfortunately although a Virtualmin backup covers most of what it needed it doesn't cover it all. It doesn't backup webmin or any files outside of /home/{domain}, other than Virtualmin settings, and domain must be a Virtualmin domain. Virtualmin does not backup any files outside of the domains it owns. So, for example, if you saved ssl certificates in /home/ssl Virtualmin would not back that up just because it was under /home.

2. Webmin Backup/Restore

Webmin has a backup and restore but unlike Virtualmin it doesn't rebuild it, backup just saves files and restore just overwrites files. Given what files Webmin will backup and restore this is very dangerous and it is easy to trash a VPS unless you are restoring exactly the same VPS, including same IP, same disk IDs, etc. (and in that case a image would be simpler and quicker). It's far more likely that you would rebuild a copy of the site and then make the copy the live site once it tests out ok. A webmin restore would set the IP in the network settings to the old IP making the VPS unreachable over SSH, as well as overwriting file tables. Webmin restore cannot be recommended as a usable method, plus it also does not backup all the necessary files.

The only practical method is a manual compare of the config files and then an intelligent manual restore of the features. Hence the full backup/restore, automatic/manual process is:

• Spin up a new VPS with Webmin-Virtualmin as described here.
• Add extra VPS features as described here.
• Restore the Virtualmin backup.
• Save a new configuration backup and compare to old configuration backup.
• Fix any significant differences by editing config files and/or installing missing programs.

3. External Backup

The next question is what to do with the backup. Virtualmin has built in Amazon S3 access but this doesn't take other backup files. My preference save the backups to a local directory and then sync that with my Amazon S3 bucket. To do this I use s3cmd, a command line tool. S3cmd does have the option to encrypt before transferring but this then stops sync working so for a simple life I rely on Amazon's server-side encryption. S3cmd is available via apt but currently not v1.5 which is the version that has the option to enable server-side encryption on Amazon. Hence this is installed using dpkg. Login using putty and do:

Then configure s3cmd, making sure to have Amazon S3 access key and secret key to hand as these will be needed. Note that Amazon recommend practice is to create a user for s3cmd and not give s3cmd your Amazon "root" keys. That way you can restrict s3cmd to just the access it needs rather than giving it everything. When logged in to Amazon S3 you can find create users under IAM->Users. Click create users and give the user a name. Download the Access key ID and Secret Access key and make sure you have this as this is the only time the secret key is available. In IAM->Users and then click "Attach User Policy". Select a policy template of AWSConnector to limit it to just moving data.

Also while logged in to Amazon s3 create a bucket to take the backups. Since all bucket names must be unique the best way to ensure this is to include your hub domain name as part of every bucket, i.e. my_hub_domain-backup would be the mirror of the local backup directory.

Having got the access key and secret key configure s3cmd in putty thus:

Enter the secret key and access key when asked. Also select https. Everything else can be left blank.

4. Full Backup

This is my backup method. Vary as you wish.

1. First create the local backup directories so in putty:
   
   cd /
   mkdir backup
   cd backup
   mkdir virtualmin
   mkdir etc
   
2. Point a browser to https://new-ip-number:10000 where new-ip-number is the IP number of your VPS and login.
3. Go to Virtualmin->Backup and Restore->Scheduled Backups and click "Add a new backup schedule".
4. Expand "Features and settings" and tick everything.
5. In "Destination and format" select local and enter /backup/virtualmin/backup-%a-%d-%b-%y . Tick "Do strftime-style time substitutions on file or directory name" and tick "Create destination directory". Check selected is "One file per server" and backup level is set to "Full (all files)".
6. In "Schedule and reporting" set up email on error reporting. Set backup to every Sunday night.
7. Also in "Schedule and reporting" set up "Command to run before backup"
   
   tar -czf /backup/etc/etc.tar.gz -C / etc/
   
   
   and "Command to run after backup"
   
   s3cmd --server-side-encryption --acl-private -m binary/octet-stream --delete-removed sync /backup s3://my_domain_hub-backup
   
   
   where my_domain_hub-backup is the name of your s3 bucket.
8. Click "Create Schedule".
9. Open this new schedule and at the bottom click clone schedule. Edit the clone, in "Destination and format" to be "Incremental" and change the schedule to be every night, Monday through to Saturday.

This will create a virtualmin full backup every Sunday night and an incremental backup the rest of the week. Each backup will be in a new directory below /backup/virtualmin. These directories will have names like "backup-Fri-12-Sep-14". No backup will be automatically deleted so a manual prune will be required periodically. Alternately you can set up automatic pruning but I prefer to selectively delete so I can keep some old backups.

The backup of /etc is always full and just the latest copy is kept.

5. Full Restore

Rebuild a VPS by following "Installing Webmin/Virtualmin on a new VPS" plus any other required such as "Installing a central phpmyadmin for Webmin/Virtualmin" "Installing free SSL Certificates in Webmin/Virtualmin", etc.. Install s3cmd as described in section 3 above.

Recreate the /backup directory and restore the external backups using putty thus:

Point a browser to https://new-ip-number:10000 where new-ip-number is the IP number of your VPS and login. Go to Virtualmin->Backup and Restore->Restore Backup and select the latest Sunday (i.e. full) backup directory. Expand "Features and settings" and tick everything. Expand "Other restore options" and set "Re-allocate UIDs and GID?" to No. Click show what will be restored then click restore.

Note the default for "Re-allocate UIDs and GID?" is Yes which allows restoring virtual servers into an existing setup. As this is a full restore it is less work if the UIDs and GIDs are kept the same as this is less fixes to the config files.

Repeat for the latest backup so go to Virtualmin->Backup and Restore->Restore Backup and select the latest backup directory. Expand "Features and settings" and tick everything. Expand "Other restore options" and set "Re-allocate UIDs and GID?" to No. Click show what will be restored then click restore.

Using WinSCP save /backup/etc/etc.tar.gz to your PC in some_directory/old and expand it. Rerun the tar command in section 4

and then save the new /backup/etc/etc.tar.gz to your PC in some_directory/new and expand it. Using the method in "Comparing Configuration Files" find the changes in the set up and fix these. As you fix issues you can of course update /new with the latest and re-compare.

Note if you see a missing line, iptables..... in /etc/network/interfaces this is because you have not enabled the firewall. File /etc/fstab will of course always be different due to the a different disk id. Any missing virtual servers such as one just for testing will result in a lot of differences so it is worth considering backing up everything to save work during a restore.

Webmin-Virtualmin How-To Blog Posts