Is making a backup easy ? Perhaps. Is it easy to restore? It depends

I was asked about backing up a database before doing a migration to the next version of the software. The answer was yes – take a backup. But you need to think it through.

I have a security database (RACF). If I backup it up today, ready for a migration next week, the backup may be missing some entries. For example tomorrow, someone changes their password, or defines a new resource. If I need to restore from the backup, the restored database will not have these changes.

It gets worse. If I backup the database while is is in use, I may get inconsistent data. I start my backup, and define two resources. One resource is in the part of the database already backed up, the other resource is the part of the database which is just about to be backed up.

I restore the database from the backup. It will have the second change but not the first change.

How to backup

You need to ensure that the database is read only for users, during the work. People cannot defined resources, change passwords etc., but the migration progress can make its changes.

An easy way of doing this is to start the system in single user mode.

You backup the database just before you do the migration. You might do a backup the week before to ensure the process works, for example you have enough space, and permissions, for a backup.

Restore

Restoring is a harder problem.

If you do a migration and the migration fails, you should be able to restore the database as it was before the migration started.

If the migration seemed to work, but a week later you discover there are problems. If you restore from the backup – any changes made by end users after the migration will be missing from the backup.

You need a process to handle this, for example compare the active database with the backed up copy of the data base, and note any difference, then make the same changes.

Making changes

Someone said that planning for changes when it all works is easy – just push the button.

The hard, and often forgotten, part is planning for when things go wrong, for example you find your backup was not successful, or the migration takes longer than planned, and you have an availability deadline to meet.