Directory file dates and BACKUP

[Jeremy Begg]

Hi,

I'm moving a bunch of directories from one system to another. I used BACKUP/IMAGE to create a saveset on tape on the old system, then used BACKUP without /IMAGE to restore selected directories onto the new system. For example:

$ backup tape:saveset.bck/select=[MYDIR...] -
_$ disk:[MYDIR...]/by_owner=original

This has had the desired effect of restoring the directories I want and preserved the security. However it has set the file creation date on all the directory files (*.DIR;1) to the current date and time, NOT the date/time at which the directory was created on the old system.

I've seen this before but in this case it's rather annoying, so I was wondering if there is a way to get BACKUP to preserve the directory creation timestamp? (It preserves the timestamps on non-directory files.)

Thanks,
Jeremy Begg

[Jeremy Begg]

P.S. The image backup tape was written on OpenVMS Alpha V7.3 and the new system is running OpenVMS Alpha V8.3.

[Wim Van den Wyngaert]

If you use /include it will selectively restore the files and populate the directory file accordingly (and create the dir file). It's not optimized to select everything and thus restoring the whole directory file.

I tried with "/exclude" and then you get the correct dates.

Note that /select=[mydir...] only select the file UNDER mydir. mydir.dir will be created with default settings.

Wim

[Karl Rohwedder]

Wim,

at least on my alpha I am missing a BACKUP/INCLUDE qualifier...

regards Kalle

[Wim Van den Wyngaert]

yep. It was /select. But always had prefered /include (as exclude).

Wim

[Karl Rohwedder]

Slightly newer are the qualifiers /INPUT_FILES and /FILES_SELECTED, which allow for an input file to select the files treated.

regards Kalle

[John Gillings]

Jeremy,

This may have to do with the difference between a BACKUP [000000...] and [*...]. In the former, directory files are explicitly included in the saveset, and therefore can (in principle) be restored with correct dates and security. In the latter, the directory files are only inferred from directory paths of files in the saveset, so the attributes are unknown and cannot be restored.

You say the security was restored, so maybe they are in the saveset explicitly, but it's worth checking.

Try creating and restoring a saveset containing just the directory files. You may be able to restore that without /SELECT or /INCLUDE to create the directory structure, then lay the files on top?

[Jon Pinkley]

Jeremy,

As John Gillings noted, you may want to verify that the top level directory was really restored with the same security profile as the original.

I would recommend

$ backup tape:saveset.bck/select=[000000.MYDIR...] -
_$ disk:[000000.MYDIR...]/by_owner=original

instead of

$ backup tape:saveset.bck/select=[MYDIR...] -
_$ disk:[MYDIR...]/by_owner=original


I don't believe it is possible using backup in non-image restore mode to preserve dates on the .DIR files.

See http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1150281

I find this "feature" of backup a pain. It is probably there for the same reason that rename modifies the modification dates of files; specifically to ensure that incremental backups work correctly.

I am not aware of any way to override the behavior.

Another work around besides DFU is to use Joe Meadow's FILE program to create a "fix" file for all the directories. The easiest is to create this at the same time as the image backup is made. If that isn't a possibility, using the tape to do an image restore, followed by a run of FILE to create the "fix" file, then a non-image restore, possibly editing the "fix" file to remove all the non-applicable files, and the non-date items, followed by the execution of the fix file.

The FILE program accepts wildcards, but at least the version I have, does not include the directory specifications in the filename it uses in the "fix" file, so you would either have to fix the program so it was included, or write a command procedure to run FILE once for each directory level (but not for the leaf .DIR files).

I.e. for a disk with [JEREMY.TEST] and [BEGG.TEST.ONE.TWO.THREE]

$ file [00000]*.dir/out=000000.fix
$ file [jeremy]*.dir/out=jeremy.fix
$ file [begg]*.dir/out=begg.fix
$ file [begg.test]/out=begg_test.fix
$ file [begg.test.one]/out=begg_test_one.fix
$ file [begg.test.one.two]/out=begg_test_one_two.fix

I would be looking for a fix or fixing myself before attempting to use that on a disk with a lot of directories.

Here's what a "fix" file from file looks like:

$ file disk$data4:[000000]000000.dir/out=data4_000000.fix
$ type data4_000000.fix
$ FILE 000000.DIR-
/PROTECTION=(S:RWED,O:RWED,G:RE,W:E) -
/OWNER_UIC=FILSYS -
/TYPE=VARIABLE /ORGANIZATION=SEQUENTIAL -
/ATTRIBUTES=(NOFORTRANCC,NOIMPLIEDCC,NOPRINTCC,NOSPAN) -
/CHARACTERISTICS=(NOACL_CORRUPT,BACKUP,NOBEST_TRY_CONTIGUOUS,CHARGE, -
CONTIGUOUS,DIRECTORY,NOERASE_ON_DELETE,NOFILE_CORRUPT,NOLOCKED, -
NOMARKED_FOR_DELETE,NOSPOOL,NOREAD_VERIFY,NOWRITE_BACK,NOWRITE_VERIFY) -
/VFC_SIZE=0 /RECORD_SIZE=512 /MAXIMUM_RECORD_SIZE=512 -
/END_OF_FILE_BLOCK=4 /FIRST_FREE_BYTE=0 -
/HIGHEST_ALLOCATED_BLOCK=16 -
/DEFAULT_EXTEND_QUANTITY=0 -
/BUCKET_SIZE=0 -
/GLOBAL_BUFFER_COUNT=0 -
/DIRECTORY_VERSION_LIMIT=0 -
/VERSION_LIMIT=1 -
/JOURNAL=(NOJOURNAL,NOAIJNL,NOATJNL,NOBIJNL,NORUJNL,NONEVER_RU,NOONLY_RU) -
/CREATION_DATE=" 8-FEB-1996 17:02:38.25" -
/REVISION_DATE=" 8-FEB-1996 17:02:38.25" /NUMBER_OF_REVISIONS=1 -
/EXPIRATION_DATE="12-MAR-2008 03:38:23.06" -
/BACKUP_DATE="11-MAR-2008 22:50:37.93"
$

The fix file is just a DCL command procedure with the command "FILE" followed by the filename and all the attributes to set for the specified file.

As you can see, the filename is just listed as "000000.DIR", it does not include a device or directory, so the assumption is that you will have your default directory set to the directory containing the file you are fixing. You also will probably want to strip all the non-date related stuff with an editor.

Jon

[Jan van den Ende]

Re Jon:

>>>
$ backup tape:saveset.bck/select=[000000.MYDIR...] -
_$ disk:[000000.MYDIR...]/by_owner=original
<<<

Well, that IS a matter of opinion (or perhaps VERY well knowing BACKUP & VERY accurate formulation), but, as a consequence of inaccurate using [000000.-whatever- in BACKUP output specifications, I have had to deal many times with things like:
disk:[000000.000000...000000.-whatever-]
( repeat the 000000.DIR from 2 to 20+ times)

All kinds of things stop functioning, and repair exists in
$ SET DEF disk:[000000.000000] ,
followed by a tedious cycle of repeated
$ RENAME 000000.DIR XXX.DIR
$ RENAME [.XXX]*.*.* []
$ DELETE XXX.DIR.

until no more 000000.DIR is found.

All in all, I have come to DETEST the [000000.-whatever-] construct, for normally I only get an angry customer "Things just refuse to work", without even a reference to a (partial) restore. Experience has tought me to look for 000000.DIR in all potentially involved directory trees first, but even that is sometimes a non-trivial exercise.

PS. I normally put constructs like -whetever- between angle brackets, but today ITRC has once again a flairup of refusing those because it might be some HTML malware. Bweuh!
I had to replace them with something I hope will not be blocked.

fwiw

Proost.

Have one on me.

jpe

[Jon Pinkley]

Jan,

My suggested alternative is flawed, although I was not able to reproduce the problem you describe.

It just didn't do anything different than the original.

For restoring specific directories from an image backup, the only way I can get backup to recreate an ACL on the top level directory is to to two backup operations: Using Jeremy's original as a template:

$ backup tape:saveset.bck/select=[000000]mydir.dir disk:[000000]mydir.dir/by_own=orig !restore top level directory with any ACL
$ backup tape:saveset.bck/select=[MYDIR...] disk:[mydir...]/by_own=orig

If you leave off the first, the ownership and protection appear to be set correctly (same as original .dir file), but any ACL is just dropped.

I tried several things, and the thing that really didn't work well was:

$ backup /sel=[000000...] disks:[000000...]. This actually migrated files from [mydir] to [000000].

When doing incremental backups these are the commands that I find to work correctly:

On backup:

$ backup disk:[000000...]*.*;*/modified/since=backup

On restore:

$ backup/incremental disk:

Jon

See attached for log of testing.