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
Could UNIX backups maintain the NT information, when you have the Legato backup agent running on the netapp box?
At 7:19 PM -0800 2/18/99, Benn, Paul wrote:
}}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov (925) 422-4018 Page: 423-7705x57152
Jim Harm wrote:
Could UNIX backups maintain the NT information, when you have the Legato backup agent running on the netapp box?
By "running on the netapp box" I assume you mean running the Legato client software on the filer as opposed to using either CIFS or NFS to get the data.
When we have the Legato backup software running on the Netapp box it will capture both the Unix and NT attributes. This product is still under developement however.
+----- On Fri, 19 Feb 1999 10:11:17 PST, Jim Voll writes: | Jim Harm wrote: | > | > Could UNIX backups maintain the NT information, when you have the | > Legato backup agent running on the netapp box? | | By "running on the netapp box" I assume you mean running the | Legato client software on the filer as opposed to using | either CIFS or NFS to get the data. | | When we have the Legato backup software running on the Netapp box | it will capture both the Unix and NT attributes. This product | is still under developement however.
We, like a lot of others have been waiting for a while for this client and we look like waiting a while longer. I have wondered since I heard that the client would written in Java who in their right mind would use Java for such an application. We have enough trouble getting the data off of our Auspexes (Auspices?) with a real sparc and yet you expect a virtual machine to be up to the task.
I understand why Java was chosen, I just don't understand why anyone thought that it would work.
/Michael
Michael Salmon writes:
...
...
It remains to be seen whether or not we're crazy, but perhaps I can convince you that we're not *completely* crazy.
I understand your skepticism, because running the entire backup data flow through Java would probably not result in acceptable performance.
Our idea is to use Java to execute the Legato daemons, and to direct the data movement, but to provide new primitives in WAFL that allow Java to say things like: "stream the data from this inode to this network connection." I'm not sure what all WAFL primitives Jim ended up adding to boost performance, but hopefully you get the idea. We're not talking about the normal Java I/O library here.
So Java orchestrates the backup, but the data flow itself goes directly from WAFL to the network, using the same basic code path as NFS, CIFS or HTTP.
Dave
-
Benn, Paul -
Dave Hitz -
Jim Harm -
Jim Voll -
Michael Salmon