This document explains the difference between the Legacy Backup system and the Backup system with incremental backups. In addition, it explains how incremental backups and hard links work with the Backup system. For more information on the Backup system or Legacy Backup system, read our Backup Configuration and Legacy Backup Configuration FAQ documentation.
We strongly recommend that you only use WHM's Backup Configuration interface (WHM >> Home >> Backup >> Backup Configuration) to configure backups of your server.
The Backup and Legacy Backup systems
Incremental backups with the Legacy Backup system
The Legacy Backup system supports a single incremental backup directory. The system never deletes files within this directory and only makes the latest copy available. The system names the directory incremental and does not prune it, Ii addition, you cannot retrieve a backup beyond the point when you ran the most recent backup. For example, if you set backups for all seven days of the week, the system will not create seven days' worth of backups for any files that you updated the day prior.
Incremental backups with the Backup system
The Backup system now performs the following improvements:
- Incremental backups use the same dated directory structure as compressed and uncompressed backups.
The old incremental directory no longer exists.
If your system uses any scripts that run on the old directory, you must update them to reflect the new dated structure.
- You can use multiple retention points for incremental backups, similar to compressed and uncompressed backups. The maximum retention point setting is 9999 days.
- When you run a new incremental backup, the system will compare the previous days files with the files currently in place. The system uses the Rsync transport with the
--link-destoption to create hard links of unchanged files. This method eliminates duplication of the same files. When you prune or delete a file, the system does not delete similar files. The files will still point to the same data. However, when you delete or prune the last file name that points to the data, the system will allow you to write over data for new files.
- Currently, the system only handles accounts incrementally, not system backups.
Backup system example
The following example shows you how incremental backups and hard links work with the Backup system. For this example, set up the following rules:
For this example, creation of this user is set to April 10, 2017.
- Set incremental backups to 10 retention points.
- Configure backups for every day of the week.
The next time the system runs backups, it will create an initial backup of the user's data. The following example breaks this process down. For this example, we will focus on the
index.htmlfile represents a regular file located directly on the hard drive, not a symlink or a socket.
- This hard link is the only version that currently points to the inode. Within the filesystem, a hard link points directly to the file on the hard drive.
April 10, 2017
22677893 digits represent the inode of the file data, followed by the
-rw-r--r--. file permissions, and then the number of hard links,
2, that point to that data. Since April 10, 2017 represents the first copy of this file in the backup system, the system displays only one. The system runs backups again on April 11, 2017. On this date, the
example user did not update their
index.html file, so the system hard links it to the previous day's backup. Now you see two hard links that point to the same location. Both of the files will look identical.
To see this clearly, use the wildcard,
*, to see them side by side.
April 12, 2017
The user does not update their
index.html file on April 12, 2017, so it remains the same, while the hard link count increases. You can access the data three different ways, however, they all point to the same location. If you delete one of them, the system will not delete the data on the disk. The filesystem knows that the other hard links still use the inode, so the filesystem restricts any attempt to overwrite it.
This happens for pruning as well. We will take a look at pruning soon.
April 13, 2017
The user updates their
index.html file the next day with a small (or large) change. Now when the system runs backups, it will create a new backup copy. You can see that both the file size and the inode changed. The hard link count is back to
April 20, 2017
The user makes no changes for the next six days. This results in ten days of backups on April 20th, with only two files that use disk space.
April 21, 2017
On April 21st, when the system runs backups, it will prune the oldest backup. For this example, the system prunes the backup made on April 10th.
Removal of the
/backup/2017-04-10/accounts/example/homedir/public_html/index.html file does not affect the contents of the file because the backups from April 11th and April 12th still point to the same location (inode or data).
April 22, 2017
When we skip to April 22nd, the system prunes the backups made on April 11th and April 12th. At this point, the
index.html version made at the
22677893 inode disappears. The system deleted all of the hard links to the data.
Incremental backup changes do not affect system backups. However, the system will no longer compress the on-disk copies. These raw files will now reside in the following backup directories: