Yes, there's a sample script (batch file) that can be scheduled with the AT service. Here's a snippet from section 5.2 of the doc:
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: Mark Muhlestein [mailto:mmm@netapp.com] Sent: Monday, March 01, 1999 10:56 AM To: toasters@mathworks.com Subject: Re: nightly.1 busy: snapshot rollovers not happening
The best way to do this is to create a special snapshot specifically for the backup, then delete it when the backup completes. This avoids the problem of the snapshot being changed out from under you. And this can all be automated with scripts. See Paul Benn's message for a pointer to a description of how to do this.
Mark Muhlestein -- mmm@netapp.com
-----Original Message----- From: Patrick.Day.B@bayer.com Patrick.Day.B@bayer.com To: - (052)toasters(a)mathworks.com toasters@mathworks.com; - (052)tmerrill(a)mathworks.com tmerrill@mathworks.com Date: Monday, March 01, 1999 10:48 AM Subject: Re: nightly.1 busy: snapshot rollovers not happening
I ran across this same problem when i shared the Nightly.0 for backup purposes. When the nightly.0 rolls over to the Nightly.1, the CIFS share
keeps
track and actually keeps the share mapped to nightly.1. (same thing next
night
when it rolls over to nightly.3). I posted the problem a few weeks ago
and the
only "solution" anyone could come up with was running an rsh command to
stop
and recreate the share every time the backup runs. I opted to forget the snapshot directory backup and go with a live backup of the C$\ share.
I'm getting some odd messages from one of our filers
[mountd]: DNS server for domain "CS.Arizona.EDU" not responding: Connection timed out.
The nameserver it's trying to contact as per /etc/resolv.conf seems to be up and happy. No obvious network problems between here and there, though our campus router people were playing permute-the-configuration earlier.
Is there something that can be turned on on the netapp side to get more details about what the filer is doing, name-lookup-wise?
Is there something that can be turned on on the netapp side to get more details about what the filer is doing, name-lookup-wise?
Not that I can think of offhand (although a future filer release will have somewhat more detailed error messages), but a network trace might help (if I remember correctly, the problem that inspired the more detailed error messages is that a variety of errors get reported as "Connection timed out", including some where the DNS server *did* respond but sent back an error).
<vent> So it's not good enough to login anymore as good old 'arizona-univ'; instead I have to stop and fill out some forms first? Bah. If there was a point to that exercise it quite eluded me.
BTW, 'Blossom' is now taken as a login but Bubbles and Buttercup may still be available.
(You'd be in a bad mood too if your filer's mountd ignored two perfectly good DNS servers and failed mount requests, again. Yes, stuffing everything into the local hosts file got it going again. No, I shouldn't have to maintain that file on the filer to get mounts to work.)
Oh yeah, the current support hold music is too loud, too. </vent>
-
Benn, Paul -
guy＠netapp.com -
Jim Davis