Over at SearchStorage, there’s an article at the moment about using NAS disk as a disk backup target – i.e., where (in NetWorker), the ADV_FILE device would be created.
I have to say, I strongly disagree with the notion of using NAS mounted filesystems for disk backup, even if NetWorker lets you. In short, it’s a very bad idea, and primarily for performance reasons.
Consider this – the optimal backup configuration for NAS is to use NDMP wherever possible; otherwise, if we backup the volume(s) as they are mounted on another host, every backup involves a double network transfer – once to retrieve the data from the NAS device to the mounter, and then a second transfer to have the backup product copy the data from the mounter to backup storage.
So, let me ask the obvious question – if performance issues act as a primary reason to not backup NAS via mounts, are there any compelling performance reasons why the reverse would be acceptable?
I don’t believe there are. If wishing to use array presented storage for disk backup, it would be far more advisable to use SAN storage, where the volume(s) are presented and attached as just another form of local storage.
Backing up to NAS is one of those activities that falls into the realm of “just because you can do something doesn’t mean you should do it.”
[Edit, 2009-11-15]
In recent discussions with a couple of vendors, I’m willing to entertain the notion that backing up to NAS may be acceptable in an enterprise environment, but my caveat would still be a dedicated 10 Gbit ethernet link between the NAS server and the backup server.
Hello Preston,
Always enjoy reading your blog; it is very in-depth and informative.
Have a question for you on this topic: what would you recommend for disk targets that support neither NDMP nor SAN attachments? Data Domain/Avamar fall under this category; plus the new wave of “cloud” storage, like EMC Atmos, which present both CIFS/NFS and REST interfaces.
How would/should NetWorker be configured to back up to these targets?
I would certainly do my utmost to avoid backing up to mapped CIFS or NFS shares. I do not believe that either of these are appropriate for the amount of data throughput that is required in backup-to-disk scenarios. I’m sufficiently unfamiliar with REST that I would not comment on it.
To answer the obvious question
Doing backup of NAS through mounted volume and sending backup streams to NAS volume are two very different kinds of operations.
Some points to consider
a) Backups through mounted volume involves a huge amount of filesys operations (stat, read etc) to do incremental backups. These ops have impact on both server mounting volume and NAS device. Having the backups go via NDMP usually benefits when doing incrementals by having the NAS device do a snapshot and sending one (or two) NDMP datastreams to an NDMP (or regular device).
b) Writing a savestream to a NAS volume is quite different. It is a large sequential write. If the NAS device is optimised for that kind of load (as DataDomain is) there is not much of a performance penalty.
c) In reality performance when writing to a NAS device is rarely the issue. Today most of the backups are run over gigabit network with one or two storage nodes. NAS devices usually copes quite well with 1-200MB/s range. Using dedicated storage nodes is also quite easy with network attach.
d) Price is the killer when using “regular” NAS disk (be it NetApp or Celerra). It becomes unrealistically expensive to use as backup disk. This is where DD shines. Also using Symmetrix or other high-end SAN storage is overkill.
e) Having all eggs in one basket is stupid. Using your NAS/SAN both for storage and backups is not increasing safety. You need a separate storage for the backups.