Hi all,
We have been facing some explosive growth during the past 6 months and have grown past our current backup solution. We are currently backing up via a linux box that has our 740 nfs mounted. Backups are taking sometimes 24-30 hours for incrementals and all weekend for fulls.
What I am looking for is info on how others are backing up 200G volumes on 740's or 760's. I just purchased a pair of 760's and am going to need a nice stable reliable backup system for them.
Looking at the responses sofar, most of you agree on: o directly attached tape devices and o the use of NDMP software
For the latter there are 2 to 3 solutions. What I'd like to know is how to determine the sizing of the master backup server for each of the solutions. o How much diskspace do I need for the index database? o What CPU/memory is required for handling a say 1 GB index Dbase? o Network requirements? o other?
Can anyone comment ?
Yann
On 4/13/00 at 12:27 PM, Jan.Schepers@nl.origin-it.com (Schepers, Jan) wrote:
Hi all,
We have been facing some explosive growth during the past 6 months and have grown past our current backup solution. We are currently backing up via a linux box that has our 740 nfs mounted. Backups are taking sometimes 24-30 hours for incrementals and all weekend for fulls.
What I am looking for is info on how others are backing up 200G volumes on 740's or 760's. I just purchased a pair of 760's and am going to need a nice stable reliable backup system for them.
Looking at the responses sofar, most of you agree on: o directly attached tape devices and o the use of NDMP software
For the latter there are 2 to 3 solutions. What I'd like to know is how to determine the sizing of the master backup server for each of the solutions. o How much diskspace do I need for the index database? o What CPU/memory is required for handling a say 1 GB index Dbase? o Network requirements? o other?
Can anyone comment ?
Yann
We use a Sun E250 (w/dual 400 mhz processors) filled with 9 GB drives for our ~3TB of NetApp data and found this to be inadequeate. Then again, the nature of our business produces large numbers of small files- we have more than 8 million files on just one volume of one of our filers. We eventually had to add a Sun A1000 (w/5 18 GB disks) to the E250 to have enough room to hold all of our indexes.
If I had to do it again, we would forego the local storage on the E250 and get an E220 instead and purchase the A1000 with it.
Incidentally, we use Workstation Solutions Quick Restore and directly attach Overland Data DLT7000 tape library units to each of our filers.
If you have numbers regarding how many files you're indexing in a given size volume, a company like Workstation Solutions should be able to accurately calculate your index space needs.
My personal advice on this subject from direct experience: get a lot more than you need, especially if you're growing.
Good luck, Derek Kelly www.genomecorp..com
Hi all,
We have been facing some explosive growth during the past 6 months and have grown past our current backup solution. We are currently backing up via a linux box that has our 740 nfs mounted. Backups are taking sometimes 24-30 hours for incrementals and all weekend for fulls.
What I am looking for is info on how others are backing up 200G volumes on 740's or 760's. I just purchased a pair of 760's and am going to need a nice stable reliable backup system for them.
Looking at the responses sofar, most of you agree on: o directly attached tape devices and o the use of NDMP software
For the latter there are 2 to 3 solutions. What I'd like to
4 choices that I know of (but BudTool is EOL'ing soon).
know is how to determine the sizing of the master backup server for each of the solutions. o How much diskspace do I need for the index database? o What CPU/memory is required for handling a say 1 GB index Dbase? o Network requirements? o other?
We currently have a 1.4GB index database in BudTool. During file history merges it keeps a SUN E450 with 2 400Mhz processors busy.
We're looking at upgrading our whole backup system. We will stick with an E450 as the backup server. But if we move to AIT-2 drives (from the DLT4700s) we may consider trunking to back up our SUNs to the library (currently we have a private 100BaseT network).
I'm curious about something here.
First, some background. I recently set up a backup system I really, really like. It's on a Linux fileserver, no netapps in this picture. It's backing up c. 60GB of disk, a single root drive and a 50GB RAID-5 with a hot spare, to another RAID-5 set, about 130GB, with no hot spare. I have a cronjob set to email me if a drive drops out of the set. I backup with a script that replicates all the data to be saved onto the backup raid set, using rsync, with the --backup-dir option to save anything that's been changed or deleted; then it takes all those changed-or-deleted files and bzip2s them into timestamped archives. When the backup partition gets over 90% full it commences deleting those bzip2-ed archives, starting with the oldest, until it's back down under 80% full. This gives me months of coverage and I never have to change a tape, and the cost of the drives is less than the cost of a suitable capacity tape drive to back up 60GB of data.
So anyway, enough with background, the question is, how come I don't hear anyone advocating using Netapp's snapshots as a backup strategy? Netapps don't lose data; it's not like WAFL or Netapp's RAID or any other bits are so bug-ridden that they don't do their job.
And you can buy a _Load_ of drives for what a heavy-duty industrial-strength DLT jukebox costs. Especially when you factor in the setup time, and the re-setup time every time it breaks. The Exabyte 8200 was the only tape drive I ever set up that didn't die before I switched jobs; seems like MTBF for a drive writing a tape a day is well under a year, at least in my experience in the last 6 years or so. Bleech.
-Bennett
So anyway, enough with background, the question is, how come I don't hear anyone advocating using Netapp's snapshots as a backup strategy? Netapps don't lose data; it's not like WAFL or Netapp's RAID or any other bits are so bug-ridden that they don't do their job.
Whoever isn't using NDMP has to be using snapshots - we run budtool and didn't get the NDMP option, which means it's using the snapshots to backup.
I know what you mean, I haven't heard anyone else advocate it, but I presumed that was because it's considered the "Default" way of backing up.
----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO
On Thu, 13 Apr 2000, Jay Orr wrote:
Whoever isn't using NDMP has to be using snapshots - we run budtool and didn't get the NDMP option, which means it's using the snapshots to backup.
Even NDMP triggers a dump from the Netapp, which creates a snapshot for the duration of the dump.
On Thu, 13 Apr 2000, Jay Orr wrote:
Whoever isn't using NDMP has to be using snapshots - we run budtool and didn't get the NDMP option, which means it's using the snapshots to backup.
If you're using NDMP you're using snapshots.
Tom
On Thu, 13 Apr 2000, Bennett Todd wrote:
So anyway, enough with background, the question is, how come I don't hear anyone advocating using Netapp's snapshots as a backup strategy? Netapps don't lose data; it's not like WAFL or Netapp's RAID or any other bits are so bug-ridden that they don't do their job.
Snapshots don't last forever (in this business, greater than a few years), and you can't say that disk space on a Netapp is cheaper than tape. They are great for short-term file recoveries (and even filesystem recoveries, if you use SnapRestore), but not as your only backup solution.
On Thu, 13 Apr 2000, Bennett Todd wrote:
So anyway, enough with background, the question is, how come I don't hear anyone advocating using Netapp's snapshots as a backup strategy? Netapps don't lose data; it's not like WAFL or Netapp's RAID or any other bits are so bug-ridden that they don't do their job.
NetApp does. I used snapmirror to send a copy of our data to another location. You could also do the same with one filer.
I asked NetApp to add functionality of "spoofing" the filehandles on the destination volume so that no client reboots would be necessary in order to switch to the other volume without stale NFS filehandles. This was really done for data migration, but doing it would be equivalent to rolling back the snapshot in case of disaster recovery as far as clients are concerned.
Tom
P.S. I was told about a month ago that my request was to be implemented in one of the future releases. It may be in already, I haven't heard about it yet.
On Thu, 13 Apr 2000, Schepers, Jan wrote:
Looking at the responses sofar, most of you agree on: o directly attached tape devices and o the use of NDMP software
If I may put my 2 cents worth in...
First of all as I understand NDMP (which isn't that well - feel free to enlighten me if I'm mistaken) it's just a different standard of dump of sorts, so other then being able to dump a netapp directly connected tape drive there is no advantage to using it (i.e. if you're backing up over a network, same performance of dump vs. NDMP backups). This would put the two points above together as one.
Second, direct connect isn't necessarly the fastest - for instance, many tape drives have throughput of less then 10M Bytes/sec. If you have 100Mb ethernet, thats ~11M Bytes/sec, so you're getting the same throughput and the bottleneck is still the tape drive. If you have a seperate "backup" network of 100Mb ethernet and backup through the network, time is saved if you use a backup package that interleaves backups (i.e. combines backup streams) - then the tape drive isn't waiting for one machie to feed it data. Kick this up to Gigabit and you would outperform the tape drive. Also, with this method you have less unused backup media and better media inventory management.
However, there are things that can affect throughput of networked backups - NFS latencies, traffic on the ethernet, etc.
SO, as I see it, there isn't really a quick-and-dirty rule of thumb on this. The factors that would have to be considered are :
1) Tape throughput 2) Network throughput 3) Backup software methodology.
all of these weigh close to equal in the equasion of "what's the best way to do it", so unfortunately I don't see an easy rule of thumb..
Of course, I'm never one to trust an easy answer either - so maybe it's just me ;p
----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO
-
Bennett Todd -
Brian Tao -
Derek Kelly -
Jay Orr -
Jeff Bryer -
Schepers, Jan -
tkaczma＠gryf.net