Probably a dumb question, but I just had a gigantic Sunday brunch buffet, so my brain is halfway into a food coma. ;-) Is it possible to have rsh return 0 or 1 depending on the success of a command executed on a filer? For instance, I want my backup scripts to kick off a "snap create" before they proceed, but I want to check the exit status of the rsh so I have a chance to abort and notify the operator if the snapshot is not created.
The following somewhat crude perl from a backup script I wrote does what you want: (logging code removed) Hope this helps, it has worked for us for years.
Graydon Dodson grdodson@lexmark.com
--------------------------------------------------------------------- sub Snap_Create { my $netapp = shift; my $snapname = shift; my @volumes = @_;
my $vol; my $rc = 1; #true
foreach $vol (@volumes) {
my $cmd = "$rsh $netapp snap create $vol $snapname 2>&1";
## Try to create Snap my $response = `$cmd`;
## Delete & try again if already exists if ($response =~ /^\s*Snapshot already exists.$/m) { ## Delete existing snap and try again &Snap_Delete($netapp, $snapname, $vol);
$response = `$cmd`;
unless ($response =~ /^\s*creating\s+snapshot(.)*$/m) { $rc = 0; &Error("Unable to create snap "$snapname" on $netapp:$vol "); } next; }
## Were we successfull the first time? unless ($response =~ /^\s*creating\s+snapshot(.)*$/m) { $rc = 0; &Error("Unable to create snap "$snapname" on $netapp:$vol "); } } # foreach vol return($rc); }
sub Snap_Delete { my $netapp = shift; my $snapname = shift; my @volumes = @_;
my $vol; my $rc = 1; #true
foreach $vol (@volumes) {
my $cmd = "$rsh $netapp snap delete $vol $snapname 2>&1";
## Try to remove Snap my $response = `$cmd`;
unless ($response =~ /^\s*deleting\s+snapshot(.)*$/m) { $rc = 0; &Warning("Unable to remove snap "$snapname" on $netapp:$vol "); } } return ($rc); }
On Sun, 5 Nov 100, Graydon Dodson wrote:
The following somewhat crude perl from a backup script I wrote does what you want: (logging code removed) Hope this helps, it has worked for us for years.
I cheat a bit specifically for the snapshot creation/deletion checks... our backup server mounts the root of each Netapp it is responsible for, so it is very easy just to look in any .snapshot directory and do a "test -d" for the appropriate snapshot name. I'm hoping that the sshd on the Netapp can return meaningful exit codes so I can have a more generic method to check on command execution and not rely on parsing stdout.
On Sun, 5 Nov 2000, Brian Tao wrote:
I cheat a bit specifically for the snapshot creation/deletionchecks... our backup server mounts the root of each Netapp it is responsible for, so it is very easy just to look in any .snapshot directory and do a "test -d" for the appropriate snapshot name. I'm
You don't need to mount the root. Every directory on a NetApp has a sekrit .snapshot directory which you can check:
15 m3:/mnt/scratch/toddc/test>ls -al total 16 drwxr-xr-x 2 toddc users 4096 Nov 7 10:03 ./ drwxr-xr-x 5 toddc users 4096 Nov 7 10:03 ../
16 m3:/mnt/scratch/toddc/test>ls -al .snapshot total 40 drwxrwxrwx 8 root root 16384 Nov 7 10:01 . drwxr-xr-x 3 toddc users 4096 Nov 7 10:03 .. ---------- 1 root root 0 Jan 28 1999 hourly.0 ---------- 1 root root 0 Jan 28 1999 hourly.1 ---------- 1 root root 0 Jan 28 1999 hourly.2 ---------- 1 root root 0 Jan 28 1999 nightly.0
(The "u" option to `ls` only seems to work at the root level, however.)
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
"Todd C. Merrill" tmerrill@mathworks.com writes: [...]
You don't need to mount the root. Every directory on a NetApp has a sekrit .snapshot directory which you can check:
15 m3:/mnt/scratch/toddc/test>ls -al total 16 drwxr-xr-x 2 toddc users 4096 Nov 7 10:03 ./ drwxr-xr-x 5 toddc users 4096 Nov 7 10:03 ../
16 m3:/mnt/scratch/toddc/test>ls -al .snapshot total 40 drwxrwxrwx 8 root root 16384 Nov 7 10:01 . drwxr-xr-x 3 toddc users 4096 Nov 7 10:03 .. ---------- 1 root root 0 Jan 28 1999 hourly.0 ---------- 1 root root 0 Jan 28 1999 hourly.1 ---------- 1 root root 0 Jan 28 1999 hourly.2 ---------- 1 root root 0 Jan 28 1999 nightly.0
(The "u" option to `ls` only seems to work at the root level, however.)
The "u" option (i.e. looking at the atime values) will work whenever the entries in .snapshot are "genuine", i.e. the directory actually existed at the time of the particular snapshot, e.g.
$ pwd /home/cet1 $ ls -alu .snapshot total 920 drwxrwxrwx 20 root root 4096 Dec 20 1999 . drwxr-xr-x 95 cet1 cet1 24576 Nov 7 16:35 .. drwxr-xr-x 94 cet1 cet1 24576 Nov 7 16:00 hourly.0 drwxr-xr-x 94 cet1 cet1 24576 Nov 7 12:00 hourly.1 drwxr-xr-x 94 cet1 cet1 24576 Nov 7 08:00 hourly.2 [...] drwxr-xr-x 92 cet1 cet1 24576 Oct 30 00:00 weekly.1 drwxr-xr-x 92 cet1 cet1 24576 Oct 23 00:00 weekly.2 drwxr-xr-x 91 cet1 cet1 24576 Oct 16 00:00 weekly.3
but not if they are dummy entries indicating that it didn't:
$ mkdir temp $ ls -alu temp/.snapshot total 16 drwxrwxrwx 20 root root 4096 Dec 20 1999 . drwxr-xr-x 3 cet1 cet1 4096 Nov 7 17:12 .. ---------- 1 root root 0 Mar 26 1999 hourly.0 ---------- 1 root root 0 Mar 26 1999 hourly.1 ---------- 1 root root 0 Mar 26 1999 hourly.2 [...] ---------- 1 root root 0 Mar 26 1999 weekly.1 ---------- 1 root root 0 Mar 26 1999 weekly.2 ---------- 1 root root 0 Mar 26 1999 weekly.3
e.g., for an account created last night:
$ ls -alu /home/spqr9/.snapshot total 40 drwxrwxrwx 20 root root 4096 Dec 20 1999 . drwxr-xr-x 3 spqr9 spqr9 4096 Nov 7 04:30 .. drwxr-xr-x 2 spqr9 spqr9 4096 Nov 7 16:00 hourly.0 drwxr-xr-x 2 spqr9 spqr9 4096 Nov 7 12:00 hourly.1 drwxr-xr-x 2 spqr9 spqr9 4096 Nov 7 08:00 hourly.2 [...] ---------- 1 root root 0 Mar 26 1999 weekly.1 ---------- 1 root root 0 Mar 26 1999 weekly.2 ---------- 1 root root 0 Mar 26 1999 weekly.3
In fact all of the ctime, mtime & atime for those dummy entries are set to the time of creation of the volume.
The root directory is safest for this sort of thing, as it's practically guaranteed to have been there at the time of the snapshot. :-)
Maybe this should be an RFE: as the attributes of the dummy entries could be anything NetApp wanted them to be, the atime could be the time of the snapshot as they are for the (comparatively) real ones.
It occurs to me to wonder what the atime of the .snapshot directory itself is ("Dec 20 1999" above). [The mtime and ctime are the time the last snapshot was taken.] I think that was when I upgraded from 5.2.2 to 5.3.4R2.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
On Tue, 7 Nov 2000, Todd C. Merrill wrote:
You don't need to mount the root. Every directory on a NetApp has a sekrit .snapshot directory which you can check:
Oh, I know... I'm mounting the filers from their root for other reasons, not so I can see the .snapshot directory. ;-)
(The "u" option to `ls` only seems to work at the root level, however.)
Until next time...
Hrm... it seems to work for me from any point in the filesystem. You're talking about showing the access time of the snapshot subdirectories, so you know when they were taken?
office:/home/taob/public_html/Images/olympus_e10/.snapshot% ls -lut total 80 drwxr-xr-x 5 taob sysadmin 4096 Nov 7 20:00 hourly.0 drwxr-xr-x 4 taob sysadmin 4096 Nov 7 19:00 hourly.1 drwxr-xr-x 4 taob sysadmin 4096 Nov 7 18:00 hourly.2 drwxr-xr-x 4 taob sysadmin 4096 Nov 7 17:00 hourly.3 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 16:00 hourly.4 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 15:00 hourly.5 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 14:00 hourly.6 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 13:00 hourly.7 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 12:00 hourly.8 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 11:00 hourly.9 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 10:00 hourly.10 drwxr-xr-x 3 taob sysadmin 4096 Nov 7 09:00 hourly.11 drwxr-xr-x 3 taob sysadmin 4096 Nov 6 00:00 nightly.1 drwxr-xr-x 3 taob sysadmin 4096 Nov 5 00:00 nightly.2 drwxr-xr-x 3 taob sysadmin 4096 Nov 4 00:00 nightly.3 drwxr-xr-x 3 taob sysadmin 4096 Nov 3 00:00 nightly.4 drwxr-xr-x 3 taob sysadmin 4096 Nov 2 00:00 nightly.5
(mount point is up at /home/)
-
Brian Tao -
Chris Thompson -
Graydon Dodson -
Todd C. Merrill