Why You Shouldn’t Run Backups on a NAS Server Using a Pull Strategy
NAS server devices are good for managing storage, such as hard drives, and provide that storage on the network for other servers to use. Virtual machine backups and other types of backups that involve a large volume of information are best handled at the source, i.e. on the server that manages and offers them. Instead of pulling large virtual machine files from Hyper-V servers to a NAS server, it’s more efficient to run compression and deduplication at the source and then transfer smaller delta files from the Hyper-V Server to the NAS device. This takes the CPU load off the NAS device and also dramatically reduces network traffic. No matter how capable the NAS hardware is, if a sufficient number of servers needs to be protected, either the NAS or the network will become overloaded unnecessarily when backups are “pulled” instead of “pushed” to the NAS server. Ideally you will want to reduce the load on the network as well as on the NAS server as much as possible, for best performance overall.
In addition, there are many scenarios where the “pull strategy” doesn’t work at all. SQL Server, for example, locks its data files, as do all Office applications. When you use a server backup software like BackupChain on the SQL Server itself, it is able to communicate with SQL Server and obtain a consistent live copy of all SQL database files for backup. A NAS server cannot do this remotely. The SQL Server hardware is also better equipped to compress and deduplicate backup files before they are ready for the archive; hence, a NAS server is best used for what it was designed to do: to store data and not process it.
For these main reasons we recommend installing BackupChain on your servers and workstations and using the NAS server device as the target.