- Netapps are impossible to back up
Not so. There are many ways to backup a filer. The fasted by far is direct attached SCSI though. If investing in large filers, one might consider the use of DLT for backups.
Interestingly, there was brief discussion on toasters a few weeks ago about slow backups to a local SCSI tape, when the drive was made remote the backups went MUCH faster. It seems that the additional buffering provided by the network allowed the tape drive to stream better than when it was attached locally.
In a larger environment you probably don't want to backup each fileserver separately with an attached DLT. And as NetApp doesn't support a reasonable NDMP version which allows backup over the net the only way to do a central backup is through NFS - not a very smart solution.
Hmmm, we've been using the native dump to a remote tape (DLT and 3590) using rmt protocol, we have found that we get good transfer rates (with 100Mbit and FDDI the drive streams nicely). We can restore the data using standard Unix restore (AIX and Solaris). In fact just to test our backups we routinely restore 2 Gig sections from dumps, we do other tests involving selecting a number of files at (pseudo)random and restoring them, then comparing them with the original data (first testing to see of the file has been modified since it was dumped).
Clearly this is NOT backing up through NFS. We've been doing this for several years now, before we integrated it into our standard backup scheme (home grown, we backup filesystems from a wide range of unix systems) we had a set of scripts that were run by cron to back the filers up using knowledge of the sizes of the filesystems to ensure that any one piece would fit on a tape.
Something to the effect of (our tapes are attached to stackers which load the next tape automaticly):
rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys1 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys2 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys3 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys4 rsh <host> mt -f <device> rewoffl; rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys5 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys6 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys7 rsh <host> mt -f <device> rewoffl rsh filer3 dump <level>ufbB <host>:<device> 32 35000000 filesys8 rsh <host> mt -f <device> rewoffl
Clearly this produces reasonable backup volumes and is quite straight forward. If your filesystems are larger than will fit on a single tape, you have to be a little more creative (using expect to fake interaction), or run the backup interactively.
----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw@cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU