"Melvin, Grant" wrote:
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.
If BudTool is using the dump.NetApp class then you *are* still using NDMP, but instead of directing the backup stream to local tape, its going out a socket to your SGI Origin system. Writing to the network can yield a better throughput than writing to a DLT 4000, so perhaps the SGI Origin is able to stream to a DLT 4000 faster.
I don't see how we could be using NDMP. 1) It's turned off on the filer. 2) The diag file shows that BudTool tries to connect via NDMP and fails, then tries via BudTool's service daemon and fails, and finally connects via rsh. 3) There are no active NDMP sessions on the filer when the dumps are running.
Indeed, because NDMP is turned off, BudTool no longer uses the goserver.ndmp.filter, but uses the goserver.dump.filter, which I had to manually edit to handle some of the messages that the filer's dump command issues, that the filter wasn't expecting.
It would seem clear that we are not using NDMP.
Besides the speed up in backup time, by doing it over the net to the SGI, we discovered another benefit - we can restore files directly to the filer (and deposit them anywhere on the filer, that we want). In the past, when we'd played around with the old dump.FAServer class, we couldn't restore directly to the filer.
Since BudTool is going away, I'll need to investigate all options, including NDMP solutions, though I do feel seriously burned by it. I'd rather find a solution that lets me continue to use the filer's native dump/restore across the net, without NDMP, though.
Anyone know if the two DLT4000's in a Breece Hill Q7 can be replaced with two DLT7000's? That would speed things up even further for me. I suppose I'll have to give Breece Hill a call ...
-ste