On Fri, Apr 23, 2010 at 12:24 PM, Phil Pennock <[email protected]>wrote:
> 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. > > > All snapshots are at the volume level and when you run the backup local to the filer it creates a new snap and that is what gets backed up. I imagine if you're backing up the filer externally (i.e. from a mountpoint, not NDMP or local dump) you'd want to do something similar. > > 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. > > Sound advice. -s
_______________________________________________ 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/
