According to NOW, backing up from a snapshot should place the "real" path in /etc/dumpdates:
NOW: Knowledge Base: Data ONTAP: Backup and Recovery: Backing up the Filer to Tape: FAQ_575
Q: How do I dump an already-created snapshot?
A: Essentially, you only need to specify the snapshot in the dump path. For example, to dump the hourly.0 snapshot, run:
dump 0uf rst0a /vol/vol0/.snapshot/hourly.0/rest_of_path
In pre-Data ONTAP 5.1 releases, the /etc/dumpdates table entry will look like:
/vol/vol0/.snapshot/hourly.0/rest_of_path 0 Tue Jul 28 20:39:46 1998
In post-5.1 releases, the /etc/dumpdates table entry will look like:
/vol/vol0/rest_of_path 0 Tue Jul 28 20:39:46 1998
Note that if you are running a pre-multi-volume release (pre-5.0, in other words), the command will look like:
dump 0uf rst0a /.snapshot/hourly.0/rest_of_path
I'm running DOT 5.3D9. So am I doing something wrong, or is this just another example of bad documentation from NetApp?
blacklodge: ~ [635] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 blacklodge: ~ [636] # blacklodge: ~ [636] # blacklodge: ~ [636] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 /vol/fs0/.snapshot/hourly.0/home/test 0 Tue Jun 22 08:00:54 1999 blacklodge: ~ [637] #
I'm running DOT 5.3D9. So am I doing something wrong, or is this just another example of bad documentation from NetApp?blacklodge: ~ [635] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 blacklodge: ~ [636] # blacklodge: ~ [636] # blacklodge: ~ [636] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 /vol/fs0/.snapshot/hourly.0/home/test 0 Tue Jun 22 08:00:54 1999 blacklodge: ~ [637] #
This looks odd to me. I just ran a test on one of our filers and did not see this behavior. To be fair, I was running 5.3, not 5.3D9, but I couldn't see a code difference between the two versions that would affect the /etc/dumpdates behavior.
(See below for what I tested)
Could you send the exact command sequence you used - version, dump command, etc...
I'm curious to see what we're doing differently... If nothing, then I'll try upgrading to 5.3D9 and see if I can reproduce it.
Stephen Manley File System Recovery English Literature Fan
dickens> version NetApp Release 5.3: Thu Apr 1 15:34:12 PST 1999
dickens> dump 0uf rst0a /vol/vol0/etc DUMP: Dumping tape file 1 on rst0a DUMP: creating "/vol/vol0/.snapshot/snapshot_for_backup.0" snapshot. DUMP: Using subtree dump DUMP: Date of this level 0 dump: Tue Jun 22 18:20:49 1999. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol0/etc to rst0a DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 1359601 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: dumping (Pass V) [ACLs] DUMP: 1358792 KB DUMP: DUMP IS DONE DUMP: Deleting "/vol/vol0/.snapshot/snapshot_for_backup.0" snapshot.
keats% cat /t/dickens/vol0/etc/dumpdates /vol/vol0/home 0 Thu Apr 22 15:53:29 1999 /vol/vol0/ 0 Thu May 27 16:27:49 1999 /vol/vol0/etc 0 Tue Jun 22 18:20:49 1999
dickens> dump 0uf rst0a /vol/vol0/.snapshot/hourly.0/etc DUMP: Dumping tape file 1 on rst0a DUMP: Using subtree dump DUMP: Date of this level 0 dump: Tue Jun 22 16:00:05 1999. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol0/.snapshot/hourly.0/etc to rst0a DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 1359512 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: dumping (Pass V) [ACLs] DUMP: 1358703 KB DUMP: DUMP IS DONE
keats% cat /t/dickens/vol0/etc/dumpdates /vol/vol0/home 0 Thu Apr 22 15:53:29 1999 /vol/vol0/ 0 Thu May 27 16:27:49 1999 /vol/vol0/etc 0 Tue Jun 22 16:00:05 1999
dickens> dump 0uf rst0a /vol/vol0/etc/.snapshot/hourly.1 DUMP: Dumping tape file 1 on rst0a DUMP: Using subtree dump DUMP: Date of this level 0 dump: Tue Jun 22 20:00:05 1999. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol0/etc/.snapshot/hourly.0 to rst0a DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 1359512 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: dumping (Pass V) [ACLs] DUMP: 1358703 KB DUMP: DUMP IS DONE
keats% cat /t/dickens/vol0/etc/dumpdates /vol/vol0/home 0 Thu Apr 22 15:53:29 1999 /vol/vol0/ 0 Thu May 27 16:27:49 1999 /vol/vol0/etc 0 Tue Jun 22 20:00:05 1999
In message 199906221851.LAA00247@cherryhill.netapp.com, Stephen Manley wri tes:
I'm running DOT 5.3D9. So am I doing something wrong, or is this just another example of bad documentation from NetApp?blacklodge: ~ [635] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 blacklodge: ~ [636] # blacklodge: ~ [636] # blacklodge: ~ [636] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 /vol/fs0/.snapshot/hourly.0/home/test 0 Tue Jun 22 08:00:54 1999 blacklodge: ~ [637] #
This looks odd to me. I just ran a test on one of our filers and did not see this behavior. To be fair, I was running 5.3, not 5.3D9, but I couldn't see a code difference between the two versions that would affect the /etc/dumpdates behavior.
(See below for what I tested)
Could you send the exact command sequence you used - version, dump command, etc...
I'm curious to see what we're doing differently... If nothing, then I'll try upgrading to 5.3D9 and see if I can reproduce it.
[your example deleted]
Hmmm... It seems to be _another_ NDMP bug. The first example I sent out was generated by running the dump from BudTool via NDMP. I can't login to the filer and test the dump command, it has no local tape. But if I rsh the dump to the filer I get the same results you did, as seen below.
I guess it's time to open a service call. And thanks for taking time to respond.
jason
root@sauza: ~ [427] # root@sauza: ~ [427] # cd /net/bonnie/vol/fs0/ /net/bonnie/vol/fs0 root@sauza: bonnie/vol/fs0 [428] # grep etc etc/dumpdates /vol/fs0/etc 0 Fri Jun 18 22:47:07 1999 /vol/fs0/etc 1 Tue Jun 22 22:46:26 1999 root@sauza: bonnie/vol/fs0 [429] # root@sauza: bonnie/vol/fs0 [429] # rsh bonnie "dump 0uf - /vol/fs0/etc" > test.1 DUMP: creating "/vol/fs0/.snapshot/snapshot_for_backup.438" snapshot. DUMP: Using subtree dump DUMP: Date of this level 0 dump: Wed Jun 23 10:46:57 1999. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/fs0/etc to standard output DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 176853 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: dumping (Pass V) [ACLs] DUMP: 178373 KB DUMP: DUMP IS DONE DUMP: Deleting "/vol/fs0/.snapshot/snapshot_for_backup.438" snapshot. root@sauza: bonnie/vol/fs0 [430] # root@sauza: bonnie/vol/fs0 [430] # grep etc etc/dumpdates /vol/fs0/etc 0 Wed Jun 23 10:46:57 1999 /vol/fs0/etc 1 Tue Jun 22 22:46:26 1999 root@sauza: bonnie/vol/fs0 [431] # root@sauza: bonnie/vol/fs0 [431] # rsh bonnie "dump 0uf - /vol/fs0/.snapshot/hourly.0/etc" > test.2 DUMP: Using subtree dump DUMP: Date of this level 0 dump: Wed Jun 23 08:00:51 1999. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/fs0/.snapshot/hourly.0/etc to standard output DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 176820 KB. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: dumping (Pass V) [ACLs] DUMP: 178340 KB DUMP: DUMP IS DONE root@sauza: bonnie/vol/fs0 [432] # root@sauza: bonnie/vol/fs0 [432] # grep etc etc/dumpdates /vol/fs0/etc 0 Wed Jun 23 08:00:51 1999 /vol/fs0/etc 1 Tue Jun 22 22:46:26 1999 root@sauza: bonnie/vol/fs0 [433] #
-
Jason D. Kelleher -
stephen＠netapp.com