Lewis:
Please see below.
David
-----Original Message----- From: Sherbak, Tim Sent: Wednesday, July 14, 1999 8:10 AM To: Yu, David Subject: FW: Backup alternatives (again)
Hi David, I don't know as you monitor this dl- so thought I would pass it along. Tim
-----Original Message----- From: Lewis [mailto:lsa@netline.net.uk] Sent: Wednesday, July 14, 1999 7:40 AM To: toasters@mathworks.com Subject: Backup alternatives (again)
Hi everyone,
This is a first time posting from someone new to NatApps, so please bare with me. I hve been subscribed to the list for a while and read the archive to get up to speed on passed discussions.
I would appreciate it if list members could make suggestions about what alternative backup solutions are available and what kind of (un)recommendations this group puts on these alternatives.
This is a follow on from from previous discussions regarding the use of Budtool. I have taken over responsability for the backups as Shiona Mceill (former list contributer is on maternity leave).
Due to our lack of success with the implementation of Budtool and their recent demise from the UK market, we have decided not to pursue this solution.
We have looked at Netbackup from Veritas. Any comments?
Veritas introduced NDMP support for NetApp last year with 3.1.1 of NetBackup. NetBackup 3.2 is out now and adds support for NT, HP-UX, and AIX in addition to the Solaris support introduced with 3.1.1. Backups are to tape drives attached to the NetApp filer, and with 3.2, support for backup from Filer 1 to Filer 2's tape drive was implemented. Certification is done by Veritas, so support for some functionality may be staged.
We are currently looking at Quick Restore from Workstation Solutions. Any comments?
Workstation Solutions has been a very aggressive vendor and delivered a backup solution for NetApp very quickly. Backup to local tape drives, filer to filer backup (described above), and backup of Unix and NT server data to a filer's tape drive are all supported. Support is for DataONTAP 5.2 currently. A lot of different operating systems platforms are supported. For more details, please see:
As for platforms and configuration: We have 3+ F720 on 2 sites (ONTAP 5.1.2R3). 3 suns running SunOS 5.7, ATL L500 Library (DTL 7000 drive) and potentially in the future a large number of linux boxes.
NDMP has up until now been the preferred option as it seems to be the way forward with the NetApps. However, all that I have seen so far indicates that NDMP support in existing backup tools is a bit of a bolt inclusion that does not sit well with existing products or product architecture.
Most of the NDMP solutions for NetApp utilize the dump/restore functionality in DataONTAP and the SCSI passthrough facility in NDMP for robotics control. While it's true that this fits in better with certain backup software architectures than others, remember that NDMP itself will still evolve. Over time, the standard will change and be extended to provide more flexibility and better support for various architectures.
In order to configure the multiplatform network, dubious (built in) workarounds have to be made to get the system to work. These vary from additional links being wired into the library (locally attached to a NetApp), so that the unix data can be backed-up, to dummy library configuration for not local (library) attachments to NetApps.
All in all, any comments? Hopefully you will be able to tell me that I don't have a clue what I am on about and that it is all straightforward. Somehow I doubt this to be entirely the case, seeing the hoops we jumps through with budtool.
here's hoping, Lewis
David and all other respondants,
Thanks for your comments and help.
It would appear from the responses that I received, that I am barking up the right (and apparently, only) trees.
Once I have made my recommendations the matter leaves my hands, until implementation. I'll let you know if anything untoward happens.
Sorry for the quality of the grammar and speeling in the first email; sometimes I think the "sign" and "send" buttons are to close togather!
Thanks Lewis
I keep hearing about backup alternatives that use NDMP. What solutions are there if you *don't* want to use NDMP? We have several reasons for not wanting to use it.
We have had nothing but grief because we relied on using NDMP. First, NetApp's implementation had a memory leak that caused backup's to fail after the filer had been up for a month and, if not caught quickly & the filer rebooted, would cause NFS to get flaky, in that it would respond to some requests and ignore others, getting progressively worse until the filer would crash. As a result, we had to reboot the filer on a monthly basis. This lasted for over a year, during which time we were repeatedly told to upgrade to the latest version of Ontap, because it was always supposedly fixed in that release.
Because of the frequent upgrades, (which continue to happen, but for other reasons) we frequently ran into problems because of incompatibilities between NetApp's implementation of NDMP and BudTool's. Then, when we'd try to get support, we were always told that the version of Ontap we were running wasn't certified with BudTool, so it was always a major pain to get support. To be fair, BudTool broke NDMP on occasion, as well, with their upgrades. The end result was the same, however.
Lastly, we find that backing up a filer to it's local tape drive to be substantially slower than backing it up across the net to our SGI Origin 2000 media server. Not only is it faster, it puts less of a load on the filer as well.
So, having switched away from NDMP, for the above reasons, I have no burning desire to switch back, and am looking for backup solutions that do not require it. Although not the scope of this list, I need to back up Sun Solaris, IRIX & NT systems, as well.
What is there available?
-ste
We've used NDMP without any of the problems you have mentioned using Netbackup. We did have the same problems when using BudTool. We also use Netbackup to back up several filers using NFS mounts. We do this in the case of a filer that does not have a direct connected tape drive. It works fine over NFS, but is easily twice as slow as a direct connected DLT7000 tape drive (using a 100tx interface). Also, keep in mind that if you have any ACL's on the files they are lost when backed up via NFS. With netbackup we are able to backup filers using NDMP or NFS. We also back up Solaris, IRIX, HP-UX, and Windows NT. Standard disclaimers apply, i don't work for veritas, or hold any of their stock - just a satisfied customer, YMMV, etc. etc.
Graham
"Shaun T. Erickson" wrote:
I keep hearing about backup alternatives that use NDMP. What solutions are there if you *don't* want to use NDMP? We have several reasons for not wanting to use it.
We have had nothing but grief because we relied on using NDMP. First, NetApp's implementation had a memory leak that caused backup's to fail after the filer had been up for a month and, if not caught quickly & the filer rebooted, would cause NFS to get flaky, in that it would respond to some requests and ignore others, getting progressively worse until the filer would crash. As a result, we had to reboot the filer on a monthly basis. This lasted for over a year, during which time we were repeatedly told to upgrade to the latest version of Ontap, because it was always supposedly fixed in that release.
Because of the frequent upgrades, (which continue to happen, but for other reasons) we frequently ran into problems because of incompatibilities between NetApp's implementation of NDMP and BudTool's. Then, when we'd try to get support, we were always told that the version of Ontap we were running wasn't certified with BudTool, so it was always a major pain to get support. To be fair, BudTool broke NDMP on occasion, as well, with their upgrades. The end result was the same, however.
Lastly, we find that backing up a filer to it's local tape drive to be substantially slower than backing it up across the net to our SGI Origin 2000 media server. Not only is it faster, it puts less of a load on the filer as well.
So, having switched away from NDMP, for the above reasons, I have no burning desire to switch back, and am looking for backup solutions that do not require it. Although not the scope of this list, I need to back up Sun Solaris, IRIX & NT systems, as well.
What is there available?
-ste-- Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (908) 672-6456
"Graham C. Knight" wrote:
We've used NDMP without any of the problems you have mentioned using Netbackup. We did have the same problems when using BudTool. We also use Netbackup to back up several filers using NFS mounts. We do this in the case of a filer that does not have a direct connected tape drive. It works fine over NFS, but is easily twice as slow as a direct connected DLT7000 tape drive (using a 100tx interface). Also, keep in mind that if you have any ACL's on the files they are lost when backed up via NFS. With netbackup we are able to backup filers using NDMP or NFS. We also back up Solaris, IRIX, HP-UX, and Windows NT. Standard disclaimers apply, i don't work for veritas, or hold any of their stock - just a satisfied customer, YMMV, etc. etc.
I had a DLT4000 drive attached to my filers (an F540 & an F330) and was backing them up via NDMP with BudTool. When I replaced the F540 with an F740, I couldn't move the tape over, as F740 had a different SCSI setup, so we bagan backing it up across a dedicated 100Mb FD link to our SGI Origin 2000. We found it to be substantially faster than what the F540 could do to tape, and it got rid of the NDMP hassles. Mind you, we are not backing it up over NFS, but using BudTool's dump.NetApp class with NDMP turned off on the filer, so we're still using the filer's dump and restore, which means we don't lose any ACLs.
Yesterday, after upgrading it to 5.2.2P1, I tried backing my F330 up across the network in the same manner as my F740, and found it to be incredibly faster. It takes BudTool, via NDMP, to a local drive, 16+ hours to back up a 12GB directory, but I can back it up, using the same dump and restore, over the net to my SGI, in 1 hour and 43 minutes. The SGI is writing the data to yet another DLT4000, so it would appear that the filers are the bottleneck - that they write to tape horribly slow. So, I don't think I want to do that any more - not when flinging it across my net gives me such a huge speed up.
So, what I'm looking for is a backup solution that would let me continue using the filer's dump/restore, but to a tape drive on another system, as I'm not ready to replace my perfectly working DLT4000's with something else yet. BudTool let's me do that, but so far it doesn't look like anything else does.
And then, of course, I need to back up those other platforms I mentioned before.
-ste
We have ADSM running on an IBM RS6000 with a tape robot. We're using this as a hierarchical storage manager (HSM) for user data and for netapp backups. I have written what is essentially a modified rsh that we run on this RS6000. It fires up a dump on the netapp using the rsh service, and the dump writes to stdout. The modified rsh copies the dump output to disk on the RS6000, breaking it up into separate 1G files. (It would have been simpler to just use rsh and pipe it into "split", but it was more amusing to hack rsh.) ADSM is configured to automatically migrate these files to the tape robot. The HSM filesystem gives the illusion that all these files are on disk, but what is actually on disk is just a "stub" file and the real file is on tape.
I break the dump into 1G files because it has to fit in the disk cache in order to be migrated to or from tape. We have allocated a 5G disk cache for the HSM filesystem where we put the netapp dumps. So 1G seems to be a nice, safe, manageable, file size.
We restore with this command.
cat dumpfile.* | rsh toaster 'restore -rf - ...'
This works because cat sequentially opens each file, reads it, and closes it. Each file is migrated to disk when cat reads it, and the disk space is recovered when cat closes the file.
I'm thinking of writing a modified cat that pre-reads the next file to force its migration to disk. That way while I'm writing a file to restore, the tape robot can migrate the next file to disk. When I need the next file, it will already be there, speeding up things dramatically.
ADSM has its own internal backup system and our netapp dump files look just like ordinary data to ADSM. So ADSM backs up our backup files. This is good because if a tape in the robot goes bad and we lose just one 1G file, it would make the entire dump useless.
We can't leave dumps in the HSM filesystem indefinitely because we don't want to fill all the tapes in the robot with netapp dumps. Whenever we delete a dump, ADSM recovers the tape space. So our dumps are good for disaster recovery, but they don't go back very far. I didn't set up ADSM so I don't know how far back the ADSM backups go before that tape space is also recovered.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
-
Graham C. Knight -
Lewis -
Shaun T. Erickson -
Stephen C. Losen -
Yu, David