Knowledge Base

Website Backups

Introduction to Domain Level Backups

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.

Backup Destinations

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 .

Scheduling Backups

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, typicallyroot

  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.

Restoring Virtual Servers

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.

Backups By Domain Owners

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.

Incremental Backups

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.

Date-based Backups

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, likeSat

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.

Last Updated: 30/09/2019 03:30

A total of 0 / 1 users found this article useful.

Did you find this article useful? Yes | No