I just wanted to clarify that if a UNIX backup server is used, it must use NDMP. If a multiprotocol Filer is backed up as an NFS volume, all of the NTFS permissions will be lost. If an NT backup package is used, the NTFS permissions and the UNIX permissions are retained. WAFL also keeps an archive bit for UNIX files so that an NT package can perform incremental backups.
Keep an eye out for my new document titled "How to Integrate a Network Appliance Filer into the Windows NT Backup Model." It should be posted soon at: http://www.netapp.com/technology/apps.html
Here's a snippet from one of the sections:
5.2 Using Windows NT to Automate Snapshot Backup
The process described in Section 5.1 can be automated using features that are built into the Windows NT operating system. The Windows NT "at" scheduling service (briefly described in Section 2.4) can be used in combination with the "rsh" command to do this. Before it will work though, some minor preparation to the filer and to Windows NT will need to be performed.
First, using a text editor, edit the "etc\hosts.equiv" file on the filer. Add a line as follows:
#Use the host name or IP address. #If a host name is used, ensure #that it also appears in the /etc/hosts file. #Note the capital 'A' host_name Administrator
Alternatively, this can be done using the FilerView GUI from a web browser.
Next, from the Services option in the Windows NT Control Panel, configure the "Schedule" service to start automatically using the "Administrator" account.
Configuring a Service to Start Using a Particular User Account
Once the filer and Windows NT have been setup, schedule a batch process using the Windows NT "at" command. The following batch file, which uses NT Backup, is included as a reference:
REM In this example, 'filer5' will be used as the name of the filer REM The qtree is called 'qtmixed,' which resides on a single REM volume filer. The default volume name is vol0. REM REM Delete the snapshot created by the previous run of this process rsh filer5 -l root snap delete vol0 openfiles REM REM Turn off oplocks, telling clients to release the file rsh filer5 -l root qtree oplocks qtmixed disable REM REM Create a snapshot directory called openfiles rsh filer5 -l root snap create vol0 openfiles REM REM Re-enable oplocks rsh filer5 -l root qtree oplocks qtmixed enable REM REM Map a drive letter to the filer's root share net use f: \filer5\c$ REM REM Run the backup command - in this example NTBackup. REM Notice that '~snapshot' is used instead of '.snapshot' start /normal /b ntbackup backup f:\dir~snapshot\ /hc:on /t normal REM End of file
The above batch file (less the last few lines, launching a backup command) could also be used as a pre-job process with almost any Windows NT backup package.
-----Original Message----- From: Daniel Quinlan [mailto:quinlan@transmeta.com] Sent: Monday, February 15, 1999 11:39 PM To: Patrick.Day.B@bayer.com Cc: toasters@mathworks.com Subject: Re: Shared Snapshot directory
Patrick Day B Patrick.Day.B@bayer.com writes:
This is kinda long, so i appologize ahead of time...
You're an NT shop, eh? I really strongly recommend using the Unix dump/restore facilities built into Data ONTAP -- it's *much* faster, it takes much of the complication out of the process, it preserves both NT and Unix attributes, and it works. Also use a Unix backup server (Solaris is probably best). For backup software, we have pretty good results with BudTool.
Anyway, I think the way to do what you're trying to do is this:
- create a share of / (actually, any directory, but the example here is /) - prior to backup, create a named snapshot ("mybackup.<num>") (this is what effectively happens when using dump) - backup from /.snapshot/mybackup.<num> or /.snapshot/mybackup.<num>/dir, - after backup, remove the named snapshot
This way, you don't have to worry about the backups changing out from under you, and the CIFS locking of shares shouldn't affect you.
However, I really want to warn you away from this... IMO, these are the basic mistakes made when backing up NetApps (in order of most bad to least bad):
1. backup up over a network filesystem (NFS or CIFS) instead of dump/restore 2. backup using NT backup host instead of Unix 3. backup across network instead of directly attached SCSI jukebox 4. backup from scheduled snapshots instead of manual ones (or ones created automatically by dump) 5. backup using rsh instead of NDMP 6. (for sites with more than a few hundred GB) backup using non-scalable home-grown scripts instead of "real" backup software 7. lesser mistakes: small blocksize, too large or small of a tree in one dump, backing up during the day, etc.
I'm sure our backup guru would have a few items to add. :-)
- Dan