cancel
Showing results for 
Search instead for 
Did you mean: 

NBU 7.5 System disk incremental backup in openvms

Juannillus
Level 4
Partner Accredited

Hello all,

environment:

- NBU 7.5.0.4

- OpenVMS: 7.3

- cliente NBU OpenVMS: 7.0.1

Current situation is that we can perform full and incremental backups in a file system correctly. However, when we try to perform incremental backups in a system disk, it always backup the whole disk even when we use the /modified parameter.

As long as I know, the /modified should onle backup the files that have changed since the last backup based on the delta time, so it should work correctly. I have been reading thorugh the manual, and I can't see anywhere that you cannot do incremental backup in system disk, or that you have to perform any extra action or add a new parameter to do them.

Could anyone confirm that they've done incremental backup in system disk, and the command that they have used to do it?

We use the following commands:

- Full backup up:

backup /policy=VMS /schedule=DIA <device_to_backup>  /EXCLUDE=(*.SYS)/FULL

  /IGNORE=INTERLOCK/log /output=NBU.LOG

 

- For incremental:

 

backup /policy=VMS /schedule=DIA <device_to_backup>  /EXCLUDE=(*.SYS)/MODIFIED

  /IGNORE=INTERLOCK/log /output=NBU.LOG

 

And both times NBU backups up the whole disk.

 

Can you see anything wrong with the commands?

 

 

Regards,

 

Juan

 

12 REPLIES 12

Brook_Humphrey
Level 4
Employee Accredited Certified

incr uses the /RECORD/MODIFIED directive

This technote may help you as it does contain a little more info on how to set these up:

http://www.symantec.com/docs/TECH36003

Juannillus
Level 4
Partner Accredited

Hello Brook,

thanks for your time.

We cannot use the parameter /record because it updates the revised time of all the files that get backed up, to the date where the backup takes place. We have already tried it. Also, we would like to use the Delta time for the backups, instead of modify every single file's header. 

This is the data for one of the files that got backed up with the modifier /record:

 

Size:            3/41         Owner:    [SLS]
Created:    26-JUL-2012 04:01:42.33
Revised:    14-JUN-2013 10:13:55.63 (2)
Expires:    <None specified>
Backup:     14-JUN-2013 10:13:55.54
Effective:  <None specified>
Recording:  <None specified>
Accessed:   <None specified>
Attributes: <None specified>
Modified:   <None specified>
Linkcount:  1
File organization:  Sequential
Shelved state:      Online
Caching attribute:  Writethrough
File attributes:    Allocation: 41, Extend: 0, Global buffer count: 0, No version limit
Record format:      VFC, 2 byte header, maximum 0 bytes, longest 108 bytes
Record attributes:  Print file carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List:  None
Client attributes:  None
 

In the manual it says that you only need /record to use every file time, instead of the delta time stored in the server.

Regards,

Juan

 

 

Brook_Humphrey
Level 4
Employee Accredited Certified

according to the openvms guide:

http://www.symantec.com/docs/DOC4238

page 38 the prefered method is to let netbackup record the times itself to determine the delta time since the last backup and this is much faster than using /record/modified since you don't have to modify all the header files on the client you are backing up when you back them up.

page 115 gives a list of all the qualifiers. However if you choose to use these on the client side it does not appear that we support delta times as the /modified command will not actually change the headers itself so we have no way to know when the backup was preformed since /record was not used. And there is no qualifier to change the delta time on the os that I can find.

 

Thanks

Juannillus
Level 4
Partner Accredited

Hello Brook,

just to clarify, the incremental backups of "normal" FS work properly with the /modified parameter. We have the issue with the system FS. It does not matter which parameters we use, it always perform a full backup. We have tried with /record and /modified separate and together, and we always got a full backup backing up every file.

Do you know if it is possible to use incremental backup in system FS?

Thanks for your help.

 

Regards,

Juan

thesanman
Level 6

I simply use:

ALL_LOCAL_DRIVES:[000000...]/ignore=inter

for all my OpenVMS Netbackup policies; ALL_LOCAL_DRIVES translates to a comma sperated list on the relevant server for the drives that need to be backed up.

You can replace ALL_LOCAL_DRIVES with a device name if you want; simple enough.

Exclude lists are handled on each client via a file pointed to by NBU$EXCLUDE

Standard combinations of Full, Cumulative and Differential backups including system disk with no issues.

My advise; remove any /RECORD and /MODIFIED and let NetBackup do the work for you; it calculated dates depending on the type of backup you are doing.

If this still isn't working; as strange as it sound look at the files it is backing up; have they been modified!!

Regards, Malcolm

Juannillus
Level 4
Partner Accredited

Hello,

 

we use this command for the first full backup:

$mc NBU$BPCD backup /policy=VMS /schedule=DIARIO XXXXX:[XXXXX]*.*;*  /EXCLUDE=(*.LIS)/FULL
   /IGNORE=INTERLOCK/log /output=XXXXX:[EXPL_APL.LOG]BACKUPLOGS.LOG
 
And the following one for teh incremental:
 
$mc NBU$BPCD backup /policy=VMS /schedule=DIARIO XXXXX:[XXXXX]*.*;*  /EXCLUDE=(*.LIS)/MODIFIED /IGNORE=INTERLOCK/log /output=XXXXX:[EXPL_APL.LOG]BACKUPLOGS.LOG
 
And it always perform a full backup, copying all the files.I'm waiting for the openvms guy to send me the dates of the files before and after the backup, although he says that they haven't been modified.
 
In the meantime, can you see anything wrong with the commands?
 
Regards,
 
Juan
 

 

thesanman
Level 6

Am I correct in assuming you are driving the VMS backups from the VMS host yourself?  Thus your DIARO schedule is defined as a user backup right?  It is this schedule that will define the retention period etc etc.

Looking at the NBU client help:

/MODIFIED

       This qualifier has the same functionality as the VMS BACKUP qualifier of
       the same name. That is, only backup files with a modified date that is
       greater than the file header backup date. This qualifier is usually
       specified after a /RECORD backup.

This would mean you should have /RECORD on the full backup command line to set the "backup date" in each file header; then /MODIFIED works from this date for your cumulative incremental backup.

Combining /RECORD/MODIFIED in the same backup is equivalent to a differential incremental backup.

I have never done VMS backups this way; I drive all my VMS backups except the user driven archives from NetBackup policies and full, incremental and differential schedules; letting NetBackup do all the date calaculations and we simply don't set the backup dates on the VMS files.

Is there a reason why you are not doing this way?

Regards, Malcolm

 

thesanman
Level 6

Folling up on this; I did a test using the following and it worked for me:

$ nbu = "$nbu$bpcd"
$ nbu backup sys$sysdevice:[*...] /record /output=logs:nbu_system-disk-full.log -
          /ignore=(nobackup,interlock) /pol="dev_misc_vms_001" /sched="user_02w"
$ nbu backup sys$sysdevice:[*...] /modified /output=logs:nbu_system-disk-incr.log -
         /ignore=(nobackup,interlock) /pol="dev_misc_vms_001" /sched="user_02w"
$ exit
 

First backup was the full backup with files dates recorded (34,914 files backed up)

$dir/date=(mod, backup) sys$system:modp*.dat

Directory SYS$SYSROOT:[SYSEXE]

MODPARAMS.DAT;11      4-AUG-2010 14:59:01.81  20-JUN-2013 08:54:56.14

Total of 1 file.

Incremental did no backup this file; only 26 files backed up.

My environment is all NBU v7.5.0.5 Master and Media with VMS client at v7.5 not that I think this makes any difference.

Check your "VMS" policy type; it should be "Standard" and your "DIARO" schedule should be "User Backup" for this too all work (I believe).

Juannillus
Level 4
Partner Accredited

Hello Malcolm,

 

yes, theer's a reason behind the user backups, and it cannot be changed, they must be done this way.

From the user's guide:

However, backups that specify the /RECORD qualifier will run significantly slower than server initiated backups (which do not specify this qualifier) controlled by the servers delta time.

So, what we would like is to use the delta time for the incremental backups.

What's weird is that it works with data disks. It copy only the files modified after the last full/incremental backup. It doesn't work with system disks.

I'm also waiting for the clients update to 7.5 and see if this solve the problem, but this won't happen until monday. I have also, re-asked for the date info from the files, so I can put more info on this.

Thanks for your help Malcolm.

Regards,

Juan

 

thesanman
Level 6

Backups with /RECORD will always be slower due to the fact that file headers are updated.  It has always been a point of contention with VMS backup itself that this was always done at the end of a backup.

That said; get the client updated to v7.5; it's a very easy process over copying in the new .EXE's and it's done.  Then you have something to work from.

As I said above, it works as it should in my environment with the testing I did.  You will note I did not use /FULL but that is the "default" anyway; on the flip side to that what is the opposite of this qualifier?  There doesn't appear to be one!  /MODIFIED works with the "last backup" date.  Very strange.

Juannillus
Level 4
Partner Accredited

Hello, 

we have updated the client to 7.5 and now it modifies correctly the backup time. However, we still cannot do incremental backups of system FS. Now, we got a privilege error:

 

  %NBU-E-OPENERR, error opening file $1$DGA601:[XCOM_XXXXX]XCOM_INSTALL_PART_2.COM;2 for input
-SYSTEM-F-WRITLCK, write lock error
 
Any idea why this is happening?
 
Regards, 
 
Juan

thesanman
Level 6

I think you need to get your VMS staff involved here.  They need to look at the file mentioned above and the disk, $1$DGA601 and it's attributes.  Write lock error is exactly that; the drive would seem to be write locked.