I thought it about time that I cited the two key reasons why, if faced with a choice between NetWorker and NetBackup, I would choose NetWorker every time.
As you might expect, given my focus on backup as insurance, both of these reasons are firmly focused on recovery. In fact, so much so that I still don’t really understand why EMC doesn’t go to market with these points time and time and time again and just smack Symantec around until it’s blue in the face and begging for mercy.
Reason 1: NetBackup does not implement backup dependencies
I struggle to call NetBackup an “enterprise” backup product because of this simple fact. Honestly, backup dependencies are critically important when it comes to guaranteeing anything but last-backup recoverability.
What does this mean?
In short, as soon as a backup hits its retention period in NetBackup, it’s toast – it’s a goner.
Irrespective of whether there are any backups of the same filesystem/data set that requires the “outside retention” backup for recovery purposes.
I can’t sum this up any other way: in a backup product, I see this as recklessly irresponsible. It provides a focus on media savings that even the most miserly bean cruncher would admire. Well, until the bean cruncher’s system can’t be recovered from 6 weeks ago to fulfil audit requirements.
Reason 2: True Image Recovery is “optional”
If you’ve grown up in a NetWorker world, where the emphasis has always been, and will always continue to be on recovery, this will, like the reason above, make you soil yourself. Imagine having a full backup plus six incremental backups of a directory, and wanting to recover the filesystem from last night. Now imagine just selecting the full plus the incrementals for recovery and getting back everything generated during that time.
Even the files that had been deleted between backups. I.e., you don’t get back what the filesystem looked like at the time of the backup that you’re recovering from, but what it looked like for every backup that you’re recovering from.
NetWorker, once, in the 5.5.x stream implemented this. It was called a BUG. In NetBackup, it’s a “feature”. In order to enable a correct recovery, you have to turn on “true image recovery”, something that takes extra resources, and is typically advised that you keep the data just for a small cycle (e.g., 7 days) rather than the complete retention time for the backups.
There’s another word for this: Joke.
On another front…
As recently as December I mentioned that I wished EMC would get their act together and implement inline cloning – one of the few things where I saw that NetBackup had a distinct competitive advantage over NetWorker.
Maybe it was the glow of the cider, but I had an epiphany in Copacabana on a hill watching (probably illegal) fireworks in Avoca and Terrigal on new years eve. Inline cloning is no longer a compelling factor in a backup product. Why? Media streaming speeds have reached a point where companies with serious amounts of data just should not be implementing direct-to-tape backup solutions any more. Inline cloning was developed at a time when you’d want to generate both sets of tapes as quickly as possible, but only companies with very small data sets will find themselves not backing up to some disk unit first (be it say, ADV_FILE, or VTL, in NetWorker), and those companies won’t be constrained on backup/clone windows to a point where they’d need inline cloning anyway.
When not backing up direct-to-tape, there are several factors that mitigate the need to do inline cloning. In organisations with a very strong need for offsiting, there’s replication at a VTL or disk backup unit layer. In organisations that just need a second copy generated “as soon as possible”, doing disk/virtual tape to physical tape cloning following the backup should be fast enough to handle the cloning at appropriate performance levels.
In other words: there’s no need for EMC to implement inline cloning. As a technology, it’s a dead-end from a tape-only time. I feel somewhat silly this didn’t occur to me sooner.
One feature that I’m still waiting for in NetWorker is basic key management for use with drives that support encryption (e.g., LTO-4).
NetBackup (6.5.2+) supports some basic functionality that is ‘good enough’ for a lot of people; you can purchase more advanced features if you so wish as well. With EMC you need to purchase a key management system that is just overkill for a lot of people. Supposedly it was supposed to be in 7.5sp2, but that never materialized, and it’s not in 7.6 AFAICT.
Another nice thing that EMC could do is remove their pay wall for NetWorker documentation like Symantec does for a lot of their products. Things used to be fairly accessible on http://ftp.legato.com, but not so now. Symantec should realize that Google et al. are much better at searching than anything they could come up with, so it’d be best just to open things up so people can enter a few keywords with the “site:” modifier. The only other option is for me to download all the docs on to an OS X machine and rely on Spotlight.
Hi David,
I certainly agree there are factors in NetBackup that I like that aren’t in NetWorker. One of those used to be inline cloning, but I’ve since stopped worrying about that. Certainly though some form of basic key management would be nice – though admittedly there’s an “elegant simplicity” (aka “inherent laziness”) in saying that all key management is supported so long as the keys are done at the hardware level.
One thing that I do need to make very clear (since for some reason it didn’t seem to come out very clear) is that I wasn’t, in any way, saying that NetWorker is perfect. Anyone who has been reading my postings for long enough will see that there are components in NetWorker that drive me nuts – poor directive controls, ADV_FILE inadequacies and client operations integrated into the core GUI are all good examples of things that I dislike in NetWorker. Much as NetBackup’s GUI is generally slower and now starting to look a bit dated, it has a distinct advantage over NetWorker there in that client and server operations are all integrated nicely into the one GUI.
On the documentation front, based on some conversations I’ve had with various people in EMC at various levels of the organisations, I have high hopes that PowerLink will see some major overhauls this year. I don’t think it will fully lower the pay wall, but it might make searching within PowerLink easier. (FWIW, my take is that I download all the documentation I need, drop it into Yojimbo, and search from there. Spotlight is good, Yojimbo does it even better…)
Reflecting on it, the interesting thing about the restricted access to the EMC documentation is that clearly, based on their blogging and social networking work, they understand the Cluetrain Manifesto really well, but there’s some hump that’s stopping them on the formal documentation side.
Cheers,
Preston.
Hi Preston.
Regarding the point #2 about the true recovery in NetBackup.
In NetWorker you have the option of “Backup Renamed directories”. It’s of by default. So by default, if someone changes a name of a folder on a fileserver, that folder, and it’s content is not going to be backed up until the next Full backup. If you enable the “Backup Renamed directories”, NetWorker will backup a renamed directory as Full, even though the files inside have not changed since last Full.
It’s almost as big a joke as the NetBackup “feature”
Johannes
Hi Johannes,
It’s actually a little different to what you’ve described. With “backup renamed directories” turned off, NetWorker uses its default behaviour, which is:
(a) Backup the new directory path, but not the files previously backed up
(b) Recovery requires pulling back the new directory path + old directory path, merging.
I’ll agree it’s not ideal, but the standard lack of TIR by default in NetBackup, plus the caveats about TIR causing performance/index issues makes NBU less attractive on this front (IMHO).
Cheers,
Preston.
Sorry I wasn’t completely accurate on the NetWorker function I described.
But somehow I just can’t understand why the backup application doesn’t just backup all the files and folders within the folder hierarchy, no matter if a folder has been renamed or moved within the hierarchy. I don’t see the point in having other options.
We ran into a problem with this when doing an indexed restore of a Full + L9 and some incremental backups of a fileserver. After the restore was successfully finished, we had to go back in browstime to restore a folder that had been renamed between the Full backup and the last incremental backup needed.
Johannes
p.s. unfortunately I don’t get an email notification when you or anyone else responds to my comments on your blog.
About point #1, the dependencies mechanism looks broken since version 7.5. I reproduced this in my lab after a customer reported it and we are currently escalating this to EMC. Let me tell you that this bug got me a bit off-guard… Orphans incr savesets are not funny…