On 2010-04-23 at 08:15 -0400, Edward Ned Harvey wrote: > I was concluding precisely the opposite. Namely: To have the .snapshot > directory in every directory is nice and convenient for user access, but if > a user can "mv" some directory and suddenly it's not being backed up > anymore, not included in the previous snaps of the parent directory ... > > I think it sounds like the Netapp implementation is something I would call > "broken" albeit more convenient from a user perspective. Personally I > choose reliability over convenience any day. Especially when it comes to > backups.
My recollection, from when I admin'd NetApps, was that *BOTH* the mountpoint .snapshot dir works, and the per-directory .snapshot, so that when there aren't directory renames happening, these are all identical: /.snapshot/$snapshot_name/foo/bar/baz.txt /foo/bar/.snapshot/$snapshot_name/baz.txt /foo/.snapshot/$snapshot_name/bar/baz.txt For backups, you'd use the mount-point .snapshot, which by default is exposed to readdir(). For users, you'd use the most convenient directory to get to it, and if there was a rename, you'd use a .snapshot from an ancestor directory above the rename and then drill back down the directories. Directories are snapshotted too, .snapshot is simply a way of vectoring off and choosing which direction to go before continuing down a stored directory tree. You might also want to grab the na_* manpages from NetApp, if you have a support contract and read up on the snap command there. -Phil _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
