That is correct. Even though in most circumstances a ufsdump can be restored using a filer's "restore" command, it is NOT a supported feature.
-----Original Message----- From: Matt Phelps [mailto:mphelps@cfa.harvard.edu] Sent: Monday, June 05, 2000 6:33 PM To: Hu, Chang-Ping Cc: jkrueger@qualcomm.com; mphelps@cfa.harvard.edu; toasters@mathworks.com Subject: Re: BudTool incremental backups behaving differently when using N
It is true NetApp recommends using NetApp's dump and restore command formats. ufsrestore is also supported as an alternative way to retrieve data in case filer is unavailable. However, ufsdump is NOT supported.
C.P. Hu
Are you saying that using Solaris ufsdump to a file (or stdout, in our case) and the filer's "restore" command to restore the data is NOT supported?
-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://cfa-www.harvard.edu/~mphelps
OK, an update. I have removed the ufsdump/restore part from the equation. The same behavior exists when I move files to the NetApp with gtar using the "p" option as root to preserve file properties.
NDMP incremental dumps are still not picking up the moved files. Again, an rsh'ed Ontap "dump" command DOES pick up the moved files.
mphelps@cfa.harvard.edu (Matt Phelps) writes:
OK, an update. I have removed the ufsdump/restore part from the equation. The same behavior exists when I move files to the NetApp with gtar using the "p" option as root to preserve file properties.
NDMP incremental dumps are still not picking up the moved files. Again, an rsh'ed Ontap "dump" command DOES pick up the moved files.
Is this the same as, or related to,
| Bug ID 21837 | Product Data ONTAP | Title setAccTime() sets the atime correctly, but also sets the ctime | Problem Attempts to set only the access time of files end up changing the inode | change time as well. This is an issue for restore programs which are | trying to restore the exact state of a file.
? What do the ctimes for for the files actually look like? (use "ls -lc")
21837 is supposedly fixed in 5.3.6 (maybe even 5.3.5R2P2?).
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
chang-ping.hu＠netapp.com -
Chris Thompson -
Matt Phelps