- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- vrestore does not restore modification times
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
Discussions
Discussions
Forums
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
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
тАО10-29-2008 05:59 AM
тАО10-29-2008 05:59 AM
When I use vrestore to restore an entire file system, the file modification times for all files restored are not preserved. (modification times are set to the current time.) Am I correct in assuming that vdump/vrestore should be preserving file modification times? I am using the following commands to backup / restore.
vdump -0 -u -C -f /mnt/archive.vdump /to/be/dumped
vrestore -x -v -D /to/be/dumped -f /mnt/archive.vdump
Thanks for your time,
James
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:06 AM
тАО10-29-2008 06:06 AM
Re: vrestore does not restore modification times
Thanks again,
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:16 AM
тАО10-29-2008 06:16 AM
Re: vrestore does not restore modification times
times for all files restored are not
preserved", do you mean that the times are
restored for none of the files, or that the
times are restored for only some of the
files? (And if only some, which?)
I can't easily check it now, but I'd expect
plain files to look the same as before. I
would not be amazed if _directories_ looked
new.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:25 AM
тАО10-29-2008 06:25 AM
Re: vrestore does not restore modification times
After the restore:
All files have correct times.
Each restored directory has a modification time which is the time the directory was created by vrestore.
Can you elaborate on why you are not surprised to see directories look 'new?' Does vrestore not restore modification times for directories?
Thanks,
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:38 AM
тАО10-29-2008 06:38 AM
SolutionAh. Anticipated again.
We just had this argument among the Info-ZIP
developers a while ago in regard to how UnZip
and Zip should work. The key concept is that
the destination directories are not being
_restored_, they're being _created_, so they
_should_ look new.
It's easier to see the reason for this in the
case where not all the files in a directory
are included in the saveset. Here, the
destination directory would differ from the
original directory (because it would have
fewer files in it), so clearly it shouldn't
have the same mod-date-time in that case.
In general, an archiving program (here,
vdump) stores info _about_ a directory, but
not the actual directory contents (which
might be different on a different file
system, too). Then, the program doing the
restoration (here, vrestore) can't know what
all was in the original directory, and it's
really creating files in the new directory
(on the destination file system, which could
be different), so it really does make sense
that the destination directories should
_look_ new (because they really _are_ new).
You may find an archiving program (like, say,
"tar", or some versions of UnZip) which will
set new destination directory date-times to
match those in the source, but it might be
lying when it does so.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:43 AM
тАО10-29-2008 06:43 AM
Re: vrestore does not restore modification times
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-29-2008 06:54 AM
тАО10-29-2008 06:54 AM
Re: vrestore does not restore modification times
Not to everyone, I've found (hence that
argument I mentioned).
VMS BACKUP does the same thing usually, but
it also has a /IMAGE option, which ensures
that an entire file system (disk) is
archived, and I believe that a BACKUP /IMAGE
restoration _will_ restore the directory
date-time data. (No bets, but I believe that
that's true.)
Everything's complicated, I always say.