replication vs. backups for WAN

[ryan1212]

I have two sites connected via 100mbs link, and about 14TB of production data. I have had excellent success with server 2012\dedup (with the exception of files over 1TB)..

My plan was to use forward incremental backups and rate limit to send data to the other site. I have done the initial seeding of the data and plan to move the repository offsite later this week.

However, I learned that veeam recommends performing active fulls every month on data for consistency. This is not possible with the connection speed and the amount of data, especially since my largest VM backup takes over 26 hours to do a full on gigE, and on the 100mbs, this one job alone would take almost 12 days to send an active full! Apart from it preventing other jobs from having enough bandwidth to run, having a snapshot open for 12 days on this system is not do-able since it would grow very large.

How necessary are active full backups? Should I be using replication instead of backup to go to my WAN site to avoid this issue?

Thanks

[Yuki]

You don't have to go with active full - you can do synthetic. Just be warned that a full syn may take very long time depending on size of incrementals and your storage speed.

I personally would go with reverse incremental. Actually we do that right now on 7TB of production data with 100-300GB of daily incremental changes. We do local backups, local replicas, remote backups (to two systems) and remote replica.

Replicas =/= backup.

[foggy]

I would also mention that though reverse incremental is specifically designed for long incremental chains, it is still advised to perform active full at least once per several months due to safety considerations.

[Yuki]

Foggy - that statement reads like a disclaimer line in a contract - "We've warned you that our product may not work, so don't rely on our product telling you everything is working".

It is clear that most people who have gone with reverse incremental over WAN do this specifically because they can't really push a full backup over the wire. There is no way we can take periodic full even on a 100Mbit connection simply because our data store is 7TB and is growing. The same can be said for the OP and many others here - he won't be pushing 14TB of data on 100Mbit WAN. And the problem is not simply that it takes a lot of time to move that file over the wire, but that the VM gets locked up and stays on a single snapshot for extended period of time. Even if he wanted to seed the 14TB by sending the data through a carrier - finding units portable enough to be trusted to carrier, which can hold that much data is tough. But even if there was such a unit - taking full backup+transit+copy of the backup at destination would take more time than most business can afford to go without backing up.

So while your statement is technically correct, i doubt that many people who do WAN backups can do this.

[foggy]

So while your statement is technically correct, i doubt that many people who do WAN backups can do this.

Agree. My intention was just to keep the OP informed and let him decide on his strategy having all the valuable information in mind.

[dellock6]

+1000 on Yuki, and is true not only for WAN scenarios, even in LAN environment redoing a full backup is too much, so users do it only if needed. Even to me, statement also sounds like a liability limit "just in case", because I found it written in many threads.

Foggy, to clear it out, you officially at Veeam see any problem in long reverse incremental chains? I used even 1 year old chains, created with previous software version, and I never had any problem on restores...

Luca.

[tsightler]

The risk of long chains is that if something does happen to the VBK file (and yes, it does happen, due to hardware failure, Veeam server BSOD, etc), you can loose your entire year of backups since the rest of the chain isn't any good once the VBK file is damaged. That's certainly some risk there, although there are techniques to mitigate this. For example, when I setup offsite backups I always suggest having at least two separate volumes and occasionally copying the backup chain to the second volume. That way, if something unfortunate does happen to the VBK file, you have another copy to fall back on. Additionally, you can use a script to validate your VBK files and detect corruption earlier.

I have also used very long chains with no issues and know of many customers that also use long chains, in general, there is very little risk to the VRB files themselves, since after their creation they are generally never touched again, but the VBK file, which is undergoing constant change during each backup, can be corrupted just like any other file, due to circumstances that, in many cases, are beyond Veeam's control, and thus you have to weigh that risk against never running a full backup.

This issue impacts other large, complex solutions as well, in some cases even worse, for example, I've heard from at least 3 customers stories of losing the entire contents of their dedupe storage device. In one of those cases the customer had a replica dedupe device and their data was still OK, in the others, relying on a single appliance proved fatal to their backups.

Unfortunately, there is no 100% safe solution and thus I suspect foggy was simply pointing out one of the risks associated with never running a full backup and allowing the customer to understand those risks.

[Yuki]

so i guess the way VBK files are made is not "atomic" (a temp file is created and then appended to the main file, which either succeeds or fails and original is undamaged).

[tsightler]

so i guess the way VBK files are made is not "atomic" (a temp file is created and then appended to the main file, which either succeeds or fails and original is undamaged).

Simply appending data to a VBK file is certainly not the way it works, the VBK file is significantly more complex that just a stream of blocks, rather it's a transactional block store, with blocks and metadata that must be updated. Simply appending new data to the file would lead to the VBK file constantly growing, which would still require a new full backup at some point. The VBK file is more of a transactional blocks store, especially when running with reverse incremental, where blocks are being rolled out and marked as free, and new blocks are being written into the file.

When using forward incremental, a VBK or VIB file is not touched after it is created, so leveraging the option to create a synthetic full does provide protection from corruption while allowing only incremental data to be sent across the wire.