What is A More Efficient Backup System?

If we want to backup a resource object, the first thing we need to do is to create a backup task and configure the corresponding parameters. Then you can perform backups for this task. Each backup creates a backup copy.

The backup task has two necessary policies. One is a data retention policy, where all historical backup data does not need to be retained. Generally, users only need to keep a few recent backup copies. Next is the backup policy, which identifies when to start a backup task and automatically controls the execution of the backup task. However, slowly you will realize that the backup system is not actually user-friendly and it has many problems.

Q1: Incorrectly timed backups

For task-based mode backups, the start time or end time of the task is usually set as the backup time point. However, when the backup task contains multiple VMs, the actual snapshot time of the VMs does not coincide with the start or end time of the task.

Note that the snapshot time of a VM is what represents the state of the VM at that point in time. The backup times of the backup copies do not directly help us understand the true RPO of the VMs. This discrepancy can cause confusion when users perform disaster recovery exercises or actual recovery operations.

Q2: Hidden traps in point-in-time management

Backups based on the task mode generally take the backup data of the entire task as a full copy. When a new VM is generated under the backup task, this VM is automatically included in the next backup. Thus, the newly generated backup copy will naturally include this new VM.

But what if a VM is removed from the backup task? Let's analyze this scenario:

• If the backup task originally needed to back up three virtual machines, a1, a2, and a3. The user has set up to keep 2 backup copies.

• The 1st backup task successfully backs up 3 VMs and generates backup copy 1.

• The 2nd backup, a3 is removed and the backup task only successfully backs up a1 and a2, resulting in backup copy 2.

• The 3rd backup, same as the 2nd backup, produces backup copy 3.

After the 3rd backup completes, it is necessary to clean up backup copy 1. However, this will result in the inability to restore a3. This is contrary to the initial expectation of keeping two recoverable backup copies. The original intention was for each VM to have two preserved recoverable copies. Clearly, there is an issue with the management approach of the backup tasks.

Q3: Invalid data that cannot be deleted

The management model based on backup tasks often fails to delete invalid data as well. For example, when a backup task selects three VMs a1, a2, and a3 to be backed up and requires that the backup copy data be retained for three months. A while later, the user faced storage constraints for backups and realized that there were no critical data on a3. As a result, they decided to remove a3 from the task, hoping to free up some storage space.

At this point, you will realize that the storage space cannot be freed up. The backup data for a3 is distributed among the backup copies of the backup task, making it difficult to clean it up individually. It seems that we have no choice but to wait for a new copy to replace the old one.

Q4: Unbearable exception handling

The 1st exception, when performing a backup task, if an error occurs that the VM does not support backups, you need to re-evaluate the data source settings of the task. Be careful not only with the configuration, but also with the limitations of the backup product in detail to make sure that all the VMs included in the task can be backed up.

The 2nd exception, when a backup of a specific VM, such as a3, fails within the backup task, while the rest of the task partially succeeds. However, if you need to make sure that the RPO of the VM meets the requirements, we need to consider performing a compensating backup of a3. Yet, compensating backups are not that easy. Either the entire backup task is backed up again, which obviously extends the backup time. Or create a separate backup task for a3, which obviously becomes complicated and confusing.

The 3rd exception, when the backup proceeds to a3. For some reasons there will be a process crash, causing the whole backup task to fail. Not only the backup task fails, the data of the backed up VMs a1 and a2 will also be erased. For large-scale VMs and a large amount of data, this backup waste will become excruciating.

Q5: Confusing backup tasks

In backup task management, multiple tasks are allowed to bind to the same data source to provide greater flexibility. However, as the number of tasks increases, the overlapping of data sources increases the complexity of management. For example, within Backup Task A, "Virtual Machine a2" belongs to "Resource Pool 2" within Backup Task B. In Backup Task B, "Resource Pool 1" belongs to "Host 1" within Backup Task C. Both Backup Task A and Backup Task C include the same data source, "Virtual Machine a3."

1. Is the virtual machine already included in other backup tasks? Has it been backed up before?

2. If two tasks backup the same virtual machine, will they interfere with each other? Could this potentially lead to task exceptions?

3. When it comes to restoring a virtual machine, which backup task does it belong to? Which backup task contains the most up-to-date backup data?

Q6: Unperceived effectiveness of backups

In backup task management, backup copies may be scattered in different locations, which can add to the complexity of management. It can seem difficult to know whether a VM has been backed up, archived, or has enough copies in other locations. Almost all operations must be traced back to the backup task. This not only makes backup management more difficult, but also makes it difficult to understand the effectiveness of backup operations.

Effective backup system with Vinchin Backup & Recovery

The task-based management model obviously brings a lot of problems, and you need to find a more suitable backup management solution. As you can see, all the problems seems to be related to the backup task. But by taking a closer look, you'll realize that what really needs to be focused on are the objects that need to be protected. For example, virtual machines.

Vinchin Backup & Recovery is a backup solution designed for virtual machines of VMware, Hyper-V, XenServer, XCP-ng, oVirt, RHV, etc. It provides comprehensive and powerful VM backup and recovery features like agentless backup, instant recovery, V2V migration designed to protect and manage critical data in the virtualization environment.

Vinchin Backup & Recovery’s operation is very simple, just a few simple steps. 

1.Just select VMs on the host

2.Then select backup destination 

3.Select strategies

4.Finally submit the job

Vinchin offers a free 60-day trial for users to experience the functionality in a real-world environment. For more information, please contact Vinchin directly or contact our local partners.

Conclusion

In summary, there are a number of challenges and limitations to the current mission-based system backup model. Such as time differences, data retention issues and exception handling. To effectively address these challenges, consider a more streamlined and user-friendly backup solution. Such as Vinchin Backup & Recovery, which is designed for virtual machines. For more information, please contact Vinchin or their local partners.