- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: BACKUP Command
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2007 08:50 PM
08-02-2007 08:50 PM
BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2007 08:57 PM
08-02-2007 08:57 PM
Re: BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2007 11:21 PM
08-02-2007 11:21 PM
Re: BACKUP Command
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 12:11 AM
08-03-2007 12:11 AM
Re: BACKUP Command
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.
$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 12:33 AM
08-03-2007 12:33 AM
Re: BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 01:08 AM
08-03-2007 01:08 AM
Re: BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 01:18 AM
08-03-2007 01:18 AM
Re: BACKUP Command
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 02:14 AM
08-03-2007 02:14 AM
Re: BACKUP Command
>>>
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 03:28 AM
08-03-2007 03:28 AM
Re: BACKUP Command
I lost this argument the last time, but I've
passed your concern along to the UnZip
maintainer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 06:57 AM
08-03-2007 06:57 AM
Re: BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2007 09:18 AM
08-03-2007 09:18 AM
Re: BACKUP Command
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2007 08:21 PM
08-05-2007 08:21 PM
Re: BACKUP Command
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2007 08:26 PM
08-05-2007 08:26 PM
Re: BACKUP Command
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-07-2007 06:40 AM
08-07-2007 06:40 AM
Re: BACKUP Command
"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.