Category: Backup and restore

Do I really want to restore these datasets? – let me check first.

I needed to restore a product which had shipped files in ADRDSSU BACKUP format.

Before following the instructions and creating lots of files, I thought it would be useful to see what’s going to happen. You can do this by specifying

//S2 EXEC PGM=ADRDSSU,REGION=0M,PARM='TYPRUN=NORUN'

This shows you what will happen, but does not do any of the work.

My JCL was originally

//S1      EXEC PGM=AMATERSE,PARM=UNPACK 
//SYSPRINT DD  SYSOUT=* 
//SYSUT1 DD DISP=SHR,DSN=COLIN.PROD.TRS 
//SYSUT2 DD DSN=&&TEMP,SPACE=(CYL,(500,500)),DISP=(,PASS) 
//* 

//S2        EXEC PGM=ADRDSSU,REGION=0M,PARM='TYPRUN=NORUN' 
//SYSPRINT DD SYSOUT=* 
//DD1      DD DISP=SHR,DSN=*.S1.SYSUT2 
//SYSIN    DD * 
  RESTORE - 
  IMPORT - 
  INDDNAME(DD1) - 
  CANCELERROR - 
  DATASET(INCLUDE(**)) - 
  RENAMEU( - 
  (**.PRODANLC,COLIN.PRODANLC) - 
  (**.PRODANLE,COLIN.PRODANLE) - 
...

The output had 

ADR489I (001)-TDLOG(01), DATA SET COLIN.PRODANLC WAS SELECTED         
ADR489I (001)-TDLOG(01), DATA SET COLIN.PRODANLE WAS SELECTED


This would create datasets like COLIN.PRODANLC which I did not want to use.
I wanted to include the version and release so I used

(**.PRODANLC,COLIN.PROD321.PRODANLC) - 
(**.PRODANLE,COLIN.PROD321.PRODANLE) -

and my files came out COLIN.PROD321.PRODANLC etc.

This saved me a lot of time – having to delete many data sets with the wrong name.

Whoops – I should have defined a security profile.

When I restored from the backup, the output included

ADR755W (001)-PROTD(01), SOURCE DATA SET BETA.PROD.OUT.PRODANLC WAS GENERICALLY PROTECTED. THE TARGET DATA SET COLIN.PROD321.PRODANLC IS NOT PROTECTED BY ANY PROFILE

I defined a RACF profile

tso addsd 'COLIN.PROD321.**' uacc(NONE)

and when I retested it I did not get the ADR755W messages.

You should define the profile before you restore the files. If you do not, there is a small chance that someone could change the unprotected file. If you define the profile first – the file is protected from the moment it is created.

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.