Backup utility

[Arlene Strauss]

OpenVMS 7.3-1. We are using the SINCE=BACKUP switch with a RECORD switch on our nightly backups and getting every file on the disk backed up. I know that some of these directories and files are stale and have not been read or modified in ages, but they are getting backed up every night anyway. We are also running DISKEEPER on these disks every day. Could DISKEEPER be causing these files to be flagged as read/modified? Is there someting else I need to do to not get these directories/files? Thanks!

[Robert_Boyd]

Arlene,

How are you determining that you're getting every file backed up? There are probably 2 or 3 ways to tell. I'm curious what's tipping you off is all.

I don't know about DISKEEPER -- it should not be modifying the creation/revision/backup time stamps.

Please do a directory/full on some of the files and take a look at the BACKUP date/time stamps on them to verify that the /RECORD is actually happening. If the backup time is never getting updated, this would explain the problem too.

Also, what V7.3-1 patches do you have installed? Do you have the latest BACKUP and/or 731_UPDATE patch kits installed?

Robert

[Eberhard Wacker]

Hi Arlene,

have a look at the modification date of these files not modified in ages ($dir/date=m or better $dir/date=all). Is the modification date a new or an old one?

Maybe it would also be useful if you quote the backup command in total.

Cheers,
EW

Two remarks:
- no defragmenter tool I know does cause this
- and read access does not modify any rms file information (planned for the future if I remember right)

[John Gillings]

Arlene,

This is probably a subtlety in the way you're specifying the set of files to be backed up. Consider:

$ BACKUP/RECORD disk:[*...]*.*;* saveset

and

$ BACKUP/RECORD disk:[000000...]*.*;* saveset

If you're using the first form, the directories at the top of the disk (in the [000000] directory) aren't explicitly being backed up. They are *implicitly* backed up by saving files below them, but information like ACLs will not be correctly saved or restored. More importantly, they aren't getting a backup date recorded. You can verify this with DIR/DATE=BACKUP.

It's a *feature* of backup than /SINCE=BACKUP will consider the backup date of the file AND ALL CONTAINING DIRECTORIES, right up the directory tree! So the fact that the record date on the top level directory isn't set, or is out of the selection window will propagate to all files and subdirectories across the disk.

This behaviour is deliberate and is to ensure that all changes to a disk get correctly restored, including things like directory renames. It was introduced in about V7.1(?) timeframe.

Using the second form "[000000...]*.*;*", all directories on the disk are explicitly restored, so all information about the top level directories will be saved, AND backups dates will be written. Once you've done it once, you should find subsequent backups will select only the files that have been modified.

If you're happy that you have copies of all files, you can artificially set the backup dates for the top level directories with:

$ BACKUP/RECORD disk:[000000]*.dir nl:nl/save

BUT in future you should make sure your input specification is:

disk:[000000...]*.*;*

[Robert Atkinson]

Arlene,
you don't say here if you're using /MODIFIED in the command line?

Without this, you won't get the files you require.

Robert.

[David Jones_21]

"$ BACKUP/RECORD disk:[*...]*.*;* saveset

and

$ BACKUP/RECORD disk:[000000...]*.*;* saveset

If you're using the first form, the directories at the top of the disk (in the [000000] directory) aren't explicitly being backed up. They are *implicitly* backed up by saving files below them, but information like ACLs will not be correctly saved or restored. More importantly, they aren't getting a backup date recorded. You can verify this with DIR/DATE=BACKUP."

But if you start the cycle with an image backup /record (since /since=backup is used for incrementals), the backup date is set.

[John Gillings]

>But if you start the cycle with
>an image backup /record (since
>/since=backup is used for
>incrementals), the backup date is set.

True, but the point is

[*...]

will NOT include the top level directories in the BACKUP selection whereas

[000000...]

does. As well as not writing the backup date, the former will miss any ACLs and protection changes to the top level directories.

Bottom line, if you want to make sure BACKUP does what you want when selecting files from the entire disk, you MUST specify the files as:

[000000...]*.*;*

[Antoniov.]

Arlene,
welcome to vms forum.

About your questions this is my own opinion:
- Qualifiers /SINCE=BACKUP/RECORD are good choice to make incremental backup also if backup read files have not been modified;
- AFAIK diskeeper and other product don't change backup date. Creation date is not modified by rms interface; modified date is automatically updated by rms on close; backup date is modified by backup and some other utility (e.g. DFU).
At low level (where diskeeper works), these date can be explicitily modified and I guess Diskeeper has not reason to make this.
- There are various FAQ about backup. You can read them here Arlene,
welcome to vms forum.

About your questions this is my own opinion:
- Qualifiers /SINCE=BACKUP/RECORD are good choice to make incremental backup also if backup read files have not been modified;
- AFAIK diskeeper and other product don't change backup date; don't forget /SINCE=BACKUP/RECORD selects file
selecting backup.

Antonio Vigliotti

[Arlene Strauss]

Thanks for all your help with this. We tried the [000000...] in our backups and that was the problem. We are now getting the files we wanted in our since=backup. Thanks again!

[Antoniov.]

Arlene,
you can thank and express your satisfation assigning some points.

Antonio Vigliotti