How Would You Automate This? Data Backup and Recovery

Many applications have a way to back up and restore data. It may be specific to processes in the database, or it may be the ability to import and export data from the application and save it in a format that it can be restored directly.

There are a lot of methods that can be used, and to describe all of them is beyond the scope of this series. But let’s look at some of the common best practices for the backup and recovery of data.

The First Step: A Known Good Dataset

In the initial steps of setting up an application, you don’t need to work with a large amount of data. It is more helpful to start with small amounts of data in known quantities and confirm that the items are loaded correctly.

Here are some examples of the first types of well-known data I would want to create:

• A set of initial users with specific permissions
• A set of groups (if relevant) to organize those users
• Some content that is shared among the users or specific to a particular user
• Help documentation

With this data, I can get a good idea of what is available to the group of users at the time that I perform a backup procedure.

Setting Up Your System to Allow for Backup and Recovery

This will vary based on your application framework, what tools you are using and how you are exporting your data. For this example, I will consider an application that uses a console-type interface and allows for backup and recovery to be performed in the application itself.

For this to happen, I would need to be able to access the control panel or some kind of admin interface. Initially, I’d ask several questions:

• Do I have the correct permissions to access this interface?
• Can I ensure that unauthorized users are unable to get to these controls?
• Can I add rights to a member so that they can get access to the control panel and perform the backup and recovery operations?
• Can I establish a connection with a server and a location on the file system to create a backup?
• Can I mount and unmount the file system? What happens if I try to run a backup command when there is no mounted file system?
• Is it possible to run a backup and restore from the command line? If I do, will I get the same results?

Creating a Backup Scheme

Depending on the application, I may be able to set up a variety of backup options. A full backup will capture the entire application and all of its states at that time. Incremental backups will allow me to take a snapshot at key moments in time and only store the data that has changed since the last backup. How can I test these different examples?

With a full backup, the process is the simplest, considering I am focusing on the base data set. If I load the base data, make any changes and then perform a full backup, I can simply check to confirm that those original values from the known data set are present and any other additions aren’t there.

Incremental backups add a little bit of complexity in that I need to be able to identify changes that were made, make an incremental backup with those changes, restore the incremental backup and verify that the changes made are still there. If I made changes after the incremental backup, I want to confirm that those later changes are not reflected in the system after recovery.

I recommend the following steps:

1. Load base data from a full backup.
2. Confirm the list of users, files or other data that show the data loaded is from the full backup.
3. Add files, users or permissions. Verify that these values are present.
4. Create an incremental backup.
5. Add additional files, users or permissions.
6. Run the recovery process for the incremental backup.
7. Check that the changes made before the incremental backup are represented and that the changes made after that incremental backup are not present.

Things That Are Hard to Automate

Incremental backups are trickier to automate due to the process of ensuring that the data added at each checkpoint is handled properly. This can make for a lot of variables to track, and it’s more difficult to verify that they are created correctly.

One way to aid this process is to use a variable ${start_time} that is associated with each session of adding or removing data performed between incremental backups. If a new incremental backup is created, use a different start_time value for that session so that each set of data generated for a particular backup can be differentiated. The more incremental backups I make, the more variables with different $start_time} values I will have to coordinate, as well as values to check that the backup and recovery were performed successfully.

Another issue with testing backup and recovery is that I will need to confirm I have an available mount point, either on my local file system or a remote system, so that I can perform the backup and recovery process. While it might be easier to test this with a local mount point, it’s also important to make sure that remote network file system can be used as well, including the permissions needed to mount and unmount volumes. Having the ability to change the mount point and to confirm that the change has been made is critical to my tests.

At this point, there are some crucial questions to ask:

• Did I create a mount point that I can access?
• Do I have the right permissions to access that mount point?
• If I have made a change to the mount destination, is it reflected in the user interface?
• Can I make the changes necessary through the command line? If so, will they also be reflected in the console display?

If I am using the console to perform a backup, depending on the amount of data in the system, I may be waiting for a while before the backup is completed. In that case, I need to create a condition that looks for a message to display stating that the backup or recovery has completed.

Common Themes

Known Data Set

To perform an initial setup and have a basis for future backups, it’s important that all scripts and variables I create are based on known data in the initial data load for the application. The first full backup should be performed after the initial data load and a confirmation that the data load was successful. Running a full backup and recovery at any time during the testing will return us to the initial data state.

Permissions

Considering the volatile nature of performing backup and recovery, it’s important that I limit access to specific users whom I want to be able to perform those functions. To that end, I also want to make sure that I am testing to verify that unauthorized users cannot run a backup or recovery operation.

Cross-Browser Testing

Though the differences should be minimal, it is important to load a variety of browsers and perform these tasks to make sure that each browser is able to display the necessary fields, buttons and other aspects important to performing the backup and recovery operations.

Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.

Get a free trial

Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.