06-17-2013 02:30 AM
- NBU 220.127.116.11
- 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
- For incremental:
backup /policy=VMS /schedule=DIA <device_to_backup> /EXCLUDE=(*.SYS)/MODIFIED
And both times NBU backups up the whole disk.
Can you see anything wrong with the commands?
06-17-2013 02:59 AM
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:
06-17-2013 04:23 AM
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>
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.
06-17-2013 09:27 AM
according to the openvms guide:
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.
06-17-2013 11:48 PM
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.
06-18-2013 04:01 PM
I simply use:
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!!
06-19-2013 04:25 AM
we use this command for the first full backup:
06-19-2013 03:29 PM
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:
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?
06-19-2013 04:16 PM
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"
First backup was the full backup with files dates recorded (34,914 files backed up)
$dir/date=(mod, backup) sys$system:modp*.dat
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 v18.104.22.168 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).
06-19-2013 11:49 PM
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.
06-20-2013 12:49 AM
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.
07-01-2013 02:54 AM
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:
07-01-2013 04:06 PM
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.