The 3-2-1 rule for backups is a well known and proven method to make sure you always have a copy of your data available.
3 Copies of your data, available on 2 different media types and 1 copy is stored offsite.
The philosophy of having an onsite backup and offsite backup as well, is that on site we usually have a short backup chain on a backup storage which can deliver a high I/O throughput.
The high I/O recommendation is simple to explain; you need it when you run backups, backups copies, run health checks, compacting jobs, SureBackup jobs and possible tape jobs, all on the same set of disk spindles.
The offsite backup is less usually only used for backup copy jobs and is mainly important to hold a lot of data, for a long period of time. In a real life situation you will notice that you will, hopefully, hardly need to restore from the off site backup storage. When you do need to restore from the offsite backup, it’s often because of a DR situation; fire, leakage, hurricanes and whatnot.
I’d like to go deeper into details of the off site backup. In my experience as a consultant and trainer, this is the area where the most ‘worst practices’ are applied, so to speak. This is usually because of all the options you have for an offsite backup. A mix up between all the do’s and don’ts is easily made. “I’m only human after all”
In this blog series I’d like to start out with…
Not the NAS!
As you might know, I’m from the Netherlands. We’re a small country with some big multinationals and a backup aware public sector. However, the backbone of the economy is the SMB sector. This is also the field of business in which Veeam became well known and earned their former slogan “It just works!”. At the same time this is the sector which makes, maybe the most common, mistake when implementing an offsite backup: backup to offsite NAS with an SMB share!
“What’s wrong with having a NAS offsite?”, you might say. Well, nothing really. It’s all in the way that the NAS repository is placed. Which is usually directly behind a router and connected with a VPN connection either to the router or forwarded to the NAS itself and the NAS runs a VPN server as well.
In this scenario there are a couple things we have to take in account. First and foremost is the VPN speed. Make sure that the VPN connection speed is enough to handle your data throughput. Cheap routers can have as little as 1Mbit supported speed. Simply check the specs of the appliance/NAS and upgrade when needed.
Second is the way Veeam communicates with it’s components: The Data Mover service.
The Veeam Data Mover service is needed to store data on the backup repository. But because a NAS can’t run the data mover itself, this needs to be done by a gateway server. The use of a gateway server reduces the amount of data traveled over the WAN by a large amount when placed close to the repository.
At third place comes in, the use of the SMB protocol. Feel free to use it, but know that a major source of headaches caused to Veeam Support Engineers, is the SMB protocol.
Finally the last and least of our problems is the use of the NTFS protocol. Let me start by saying that there is nothing wrong with NTFS. It’s just really slow with file merges, even more so when used on a regular S-ATA drive. NTFS could get some issues though, when the drive isn’t formatted with the /L option, so double check this next time. Also, when used to store a GFS backup chain it uses a lot of space.
And then what?
Did you know that even a regular computer with Windows 10 and a big S-ATA disk will perform better than a NAS with SMB share? By using a PC rather than a NAS we eliminate the lack of an onsite date mover service and have the possibility to use ReFS for faster merges and a smaller backup footprint. I know, I know, ReFS is not the holy grail at the moment, but this is bound to change. Literally, any moment now with the February CU for Windows 10 and Server 2016.
Should you use Server 2016 as repository, you also have the option to use storage spaces and scale out your backup repository when needed.
I can imagine that placing a server 2016 machine is not really any comparison to an SMB NAS. Therefore, as a final alternative, I’d like to suggest a Linux Machine! No expensive license, the hardware can be as cheap or expensive as you see fit and the performance of a Linux repository is really good. The smaller the block sizes, the better the performance compared to SMB. Click here for the Linux repository system requirements.
Next time we take a look at another alternative for an offsite backup; The Cloud and it’s options, or in layman’s terms; backup to someone else’s computer.