BACKUP Command

[Sentosa]

Dear ALL,

I have backup the files with following command:
BACKUP/LOG SOURCE TARGET_SAVESET/SAV/BY_OWNER.

Then, i copy the saveset to another node & perform file restore. If i want to restore the directories & files with orginal creation date/time, could anyone know the parameter i need to specify?

Thanks,
Sentosa

[Robert Gezelter]

Sentosa,

If I understand the question in the posting correctly, the default behavior is all that you will need. No special option is required.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Sentosa,

Well, this is very rare, but in this case I DO have to disagree with Bob:

>>>
the default behavior is all that you will need. No special option is required.
<<<

That is _NOT_ true! The default behavior is to:
A. create all files in the current directory
B. have the files owned by the restorer.

The desired command would be:
$ BAckup /SAV :[...] /BY_OWN=ORIG.

The ...] construct rebuilds dir structure in the target; the /BY_OWN=ORIG maintains file attributes such as owner, protection, and dates.

If you do not need the some top part of the input directory structure, add /SELECT=[...]*.*.*

hth

Proost.

Have one on me.

jpe

[Jon Pinkley]

I have read the first two responses, and I disagree with both.

The only way I am aware of to get backup to preserve the dates on the directories is to use backup/image. That is only good for making a logically equivalent disk.

A non-image backup recreates the diretories at the time the files are restored, and the creation timestamp will not be what was on the original disk.

All user files will have the original dates, as Bob noted. In fact, I don't know of a way to get backup to change the dates on user files.

There are utilities that will allow you to modify timestamps on files, including directories. For the specific situation you are asking about, my first tool to try would be Ton Dorlan's DFU, currenlty available at Jur van der Burg's web site, www.digiater.nl. You would need to get a directory listing of the original disk with all directory files, showing at least the create date. If you are worried about preserving dates, then you probably should reset the modification date as well.

For example:

$ directory/date=(cre,mod)/noheader/notrailer/wid=(file:82) disk:[000000...]*.dir /out=sys$scratch:dir_dates.lis

That will produce a record 132 columns wide. If none of your directories are too long, then you will get 1 line of output for each file.

DEV:[MFD.SUB1.SUB2]SUB3.DIR;1 29-JUL-1996 21:52:14.50 29-JUL-1996 21:52:14.56

Then you would have to modify the directory output with a learn sequence in an editor, to be a command like

$ dfu set DEV:[MFD.SUB1.SUB2]SUB3.DIR;1 /cre="29-JUL-1996 21:52:14.50" /rev="29-JUL-1996 21:52:14.56"

And then you would need to save the modified file and execute it with @

Jon

Here's a log on Alpha VMS 7.3-2 showing that non-image backup does not preserve directory dates, and /image backup does.

First show dates of directories as they exist on a disk.

Do a non-image backup of the directories, specifying /by_owner

Show dates on the target disk. They are not preserved, they are current as of when they were recreated.

Now backup/image that disk (which has nothing but directories and reserved files) to another disk.

Notice that the dates are preserved on directory files when backup/image is used.

Log follows. If someone can produce different results, please correct me.

------------------------------------------------------------------------------

$ dir disk$syslog_21:[000000...]*.dir/date=(cre,mod)

Directory DISK$SYSLOG_21:[000000]

000000.DIR;1 20-JUN-2007 01:12:53.28 20-JUN-2007 01:12:53.28
ACCOUNTNG.DIR;1 20-JUN-2007 01:15:39.81 20-JUN-2007 01:15:39.81
AUDIT.DIR;1 20-JUN-2007 01:21:11.32 20-JUN-2007 01:21:11.32

Total of 3 files.

Directory DISK$SYSLOG_21:[ACCOUNTNG]

DELTA.DIR;1 20-JUN-2007 01:20:55.85 20-JUN-2007 01:20:55.85
OMEGA.DIR;1 20-JUN-2007 01:15:39.85 20-JUN-2007 01:15:39.85
SIGMA.DIR;1 20-JUN-2007 01:19:11.91 20-JUN-2007 01:19:11.91

Total of 3 files.

Grand total of 2 directories, 6 files.
$ init lda1: itrc /cluster=1 /header=100 /index=begin /system /own=[1,1]
$ mou/ov=id lda1:
%MOUNT-I-MOUNTED, ITRC mounted on _$4$LDA1: (SIGMA)
$ backup disk$syslog_21:[000000...]*.dir lda1:[*...]/by_own=orig/log
%BACKUP-S-CREDIR, created directory LDA1:[ACCOUNTNG]
%BACKUP-S-CREDIR, created directory LDA1:[ACCOUNTNG.DELTA]
%BACKUP-S-CREDIR, created directory LDA1:[ACCOUNTNG.OMEGA]
%BACKUP-S-CREDIR, created directory LDA1:[ACCOUNTNG.SIGMA]
%BACKUP-S-CREDIR, created directory LDA1:[AUDIT]
$ dir lda1:[000000...]*.dir/date=(cre,mod)

Directory LDA1:[000000]

000000.DIR;1 3-AUG-2007 07:29:20.38 3-AUG-2007 07:29:20.38
ACCOUNTNG.DIR;1 3-AUG-2007 07:35:54.40 3-AUG-2007 07:35:54.40
AUDIT.DIR;1 3-AUG-2007 07:35:54.63 3-AUG-2007 07:35:54.63

Total of 3 files.

Directory LDA1:[ACCOUNTNG]

DELTA.DIR;1 3-AUG-2007 07:35:54.47 3-AUG-2007 07:35:54.47
OMEGA.DIR;1 3-AUG-2007 07:35:54.52 3-AUG-2007 07:35:54.52
SIGMA.DIR;1 3-AUG-2007 07:35:54.57 3-AUG-2007 07:35:54.57

Total of 3 files.

Grand total of 2 directories, 6 files.
SIGMA::JON 07:36:43 (DCL) CPU=00:07:59.20 PF=242943 IO=1413859 MEM=301
$ sho dev ld

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
$4$LDA0: (SIGMA) Online 0
$4$LDA1: (SIGMA) Mounted alloc 0 ITRC 9878 1 1
$4$LDA2: (SIGMA) Online 0
$ mou/for lda2:
%MOUNT-I-MOUNTED, ITRC mounted on _$4$LDA2: (SIGMA)
$ backup/image lda1: lda2:
$ dism lda2:
$ mou/ov=id lda2
%MOUNT-I-MOUNTED, ITRC mounted on _$4$LDA2: (SIGMA)
$ dir lda2:[000000...]*.dir/date=(cre,mod)

Directory LDA2:[000000]

000000.DIR;1 3-AUG-2007 07:29:20.38 3-AUG-2007 07:29:20.38
ACCOUNTNG.DIR;1 3-AUG-2007 07:35:54.40 3-AUG-2007 07:35:54.40
AUDIT.DIR;1 3-AUG-2007 07:35:54.63 3-AUG-2007 07:35:54.63

Total of 3 files.

Directory LDA2:[ACCOUNTNG]

DELTA.DIR;1 3-AUG-2007 07:35:54.47 3-AUG-2007 07:35:54.47
OMEGA.DIR;1 3-AUG-2007 07:35:54.52 3-AUG-2007 07:35:54.52
SIGMA.DIR;1 3-AUG-2007 07:35:54.57 3-AUG-2007 07:35:54.57

Total of 3 files.

Grand total of 2 directories, 6 files.
$

[Jan van den Ende]

Jon,

I stand corrected on the dates issue.

Probably because I (nearly) always mu main concern is ownership and security, I (wrongly) made the same assumptions on the date part.
..shows what comes from answering "what you think is the answer" without testing :-(

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jan and Jon,

Indeed, I was referring to the FILE dates, not the dates on the directories (the OWNER I considered closed since it was part of a previous thread).

The "default" behavior I was referring to was the preservation of the dates on the actual files.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

Interestingly, when the next beta kits for
the Info-ZIP Zip and UnZip programs appear
(which may be fairly soon), I believe that
they will reset the time-date info for
directories, which will be a change from
previous [Un]Zip behavior, as well as being
different from BACKUP's behavior.

Note that restoring directory date-time info
may affect incremental BACKUP behavior, so
it's not clear that restoring these data is
really a good idea.

[Jan van den Ende]

@ Steven:

>>>
Note that restoring directory date-time info
may affect incremental BACKUP behavior, so
it's not clear that restoring these data is
really a good idea.
<<<

I think that I for one support those doubts!
(not that we will be hurt, since our backups are by pulling one shadowset member, which would immediately overwrite the recorded backup date, but still, to me it does not sound as a good idea. Perhaps one more qualifier to activate/disactivate this feature?)

fwiw

Proost.

Have one on me.

jpe

[Steven Schweda]

> [...] I for one support those doubts!

I lost this argument the last time, but I've
passed your concern along to the UnZip
maintainer.

[Jon Pinkley]

Steven Schweda>>>Note that restoring directory date-time info may affect incremental BACKUP behavior, so
it's not clear that restoring these data is
really a good idea.<<<

Yes, I remember when the rename command was changed to update the modification date on a file, with incremental backups being given as the reason for the change.

However, the check that backup makes to determine whether or not a file has changed since the previous backup is /modified/since=backup. In other words, if the modification date of the file is more recent that the backup date of the same file, then the file needs to be backed up (and if a directory, all its descendents).

I don't understand why clearing the backup timestamp wouldn't achive the same goal of making incremental backups work.

The decision to change the modification date vs. the backup date was chosen for the case of rename. Since ODS-2 has no datestamp cell to support a metadata modification (like what dir /date=attribute claims it is reporting), and the backup date was considered important by either some influential customer or developers, so they didn't feel clearing the backup date was the correct behavior.

However, my guess is that as long as zip does not keep the backup date intact, and makes sure a 64 bit binary zero is stored in the backup date field of the created directory file, there should not be any problems with incremental backups.

I haven't tested this, and I am not even sure what set of events must occur to confuse backup.

If the zip team is preserving the backup date and the modification date in addition to the original creation date, then I believe there would be a higher change of adversly affecting an incrremental backup. But without a test case, I can not say for certain.

Jon

[Steven Schweda]

> [...] as long as zip does not keep the
> backup date intact [...]

When using the Zip "-V" option, it keeps a
remarkable variety of things intact,
including backup dates. Until recently, the
still-unreleased new code was even restoring
the _size_ of a directory file, which is good
for normal files, but it seriously confused
things if not all the files in a directory
were included in the Zip archive. (It had
worked just fine on all my simple test cases,
just not on a typical real job. _That_
problem should be solved, now.)

Everything's complicated.

[Wim Van den Wyngaert]

Note that your command for making the save set :
BACKUP/LOG SOURCE TARGET_SAVESET/SAV/BY_OWNER

Is wrong. The by_owner is ignored because it is a input file qualifier and you are specifiying it as the output qualifier (which is only used in restore operations).

And good that it is ignored. As an input qualifier it selects only the files you own (what is mostly not what you want).

Wim

[Wim Van den Wyngaert]

Correction : ignored is not correct. The save set will get the owner specified. But as no uic is given, you will be the owner.

Wim

[Feldman]

Jon Pinkley wrote:

"Yes, I remember when the rename command was changed to update the modification date on a file, with incremental backups being given as the reason for the change.

However, the check that backup makes to determine whether or not a file has changed since the previous backup is /modified/since=backup. In other words, if the modification date of the file is more recent that the backup date of the same file, then the file needs to be backed up (and if a directory, all its descendents).

I don't understand why clearing the backup timestamp wouldn't achive the same goal of making incremental backups work."

The answer is that you can also do incremental backups with /SINCE=time. In fact, this was recommended in at least one VMS manual for weekly incremental backups with /SINCE=BACKUP being recommended for daily incremental backups (assuming monthly image backups). Clearing the backup date would spoil this.