Full's every 2 weeks?

[collinp]

Are there any enhancements in the works to look at creating synthetic full's beyond once a week? In the past when my repository has been full and incremental's were extended out 2 weeks, there never has been an issue with restores within the 2 week chain. I wasn't sure what the technical limitations are in allowing a synthetic full to be created every 2 weeks. I like that you can abstract your backups from your Storage Array provider by using Veeam but SAN snapshots and replication look attractive when you have 100's of TB of backups because of the fact that they are point in time backups and don't have to roll-up to a full backup on a weekly basis.

I understand that there are reverse incremental's but they are not as tape or replication friendly

[Gostev]

Hi, Collin. No immediate plans to change that, as we do want to force people to make synthetic fulls at least once a week. There are a few technical considerations behind this.

One thing coming to v8 is support for backup modes without periodic fulls (such as reverse incremental) as the source for tape jobs. We will basically synthesize the new full on the fly on required dates, as we are sending data to tape.

Now, as far as replication friendliness, reverse incremental is actually the backup mode best for block-level SAN replication. Can you clarify why you think otherwise?

[collinp]

I was comparing Veeam to backing up VM's with SAN Snapshots. If I have a 1TB backup job that I have to store for 28 days, I will have to create 4 synthetic fulls within 28 days equaling 4TB worth of fulls using Veeam. With SAN snapshots, some vendors offer pointer based snapshots that are Hyper-v aware. Each snapshot is a point in time. So to store 28 days of SAN Snapshots, I don't have to store the 4TB of fulls, but only the changes.

Yes, you would need to replicate these snapshots to a secondary array to be safe. But even after replicating, you are still storing less data for backups overall. You are tied to a SAN vendor, which is bad. The cost of storage per TB is more on a SAN then commodity storage that would be used for a Veeam Repository. But when you look at it overall, the 4TB of synthetic full's in a month can be costly. Therefore, I am asking, would it be possible to have the best of both worlds and use Veeam to create synthetic fulls every 2 weeks?

In terms of Reverse incrementals, we only have a single datacenter and AWS/tape are our offsite options. So I meant that reverse incrementals aren't tape (at this point) or AWS friendly to my knowledge. But now that I think of it, you are right, Reverse Incrementals would work well with SAN replication because only the changed blocks would replicate and not the entire Reverse Incremental Full. Is there a good product that can be used to replicate between sites if you are storing your backups on commodity storage (not a san with snapshot technology)?

[tsightler]

Reverse incremental can be very AWS friendly if you simply run a repository in the cloud and attach it via VPN to your local server.

That being said, there is an excellent product that can be used to replicate your backups between sites if your are storing your backups on commodity storage. That product is Veeam!! This is exactly what backup copy jobs are built for, that way you can use commodity storage at both sites, and keep completely independent copies of your data at the two sites, they don't even have to be on the same storage vendor (I would suggest they not be). If you replicate your backups with block storage, and something corrupts the local, it could easily corrupt the remote mirror as well, but with backup copy the remote copy is a complete chain.

So image you have a commodity disk local with reverse incremental, 1 full backup + 29 reverse points. Now at the remote site you have commodity storage updated with a Backup Copy job. Backup copies use a "forever forward" incremental approach so on that side you would have 1 full backup and 29 forward incrementals. The two copies would be completely independent of each other. Veeam even has the flexibility to keep different retention at the different sites, so perhaps you only keep 7 day locally and 30 days offsite, or the reverse. Really it's all up to you, an no SAN vendor lock in, no storage vendor lock in for the repository, nothing. I think this is the best of both worlds!

[collinp]

Or, instead of running a Veeam repository in the cloud, I could switch to Reverse Incrementals for primary backups (to reduce the 4 full's to 1) and use Veeam Backup Copy to perform block level copies to a Riverbed Steelstore appliance's CIFs share which sends deduped data to the cloud?

[tsightler]

Sure, there are a number of ways to do that, with or without a backup copy. StoreSimple, Twinstrata, and Steelstore are examples. Even Amazons own virtual storage appliance.

[collinp]

Is there a forum that discusses these 4 cloud gateways and the pro's and con's in using each with Veeam?

The reason why I suggested using a backup copy job with Riverbed and not backing up directly to the Riverbed CIFs share, is that there is per TB licensing model. I believe the Steelstore licenses based on cache size (8TB, 16TB, 32TB, etc). But I have 100TB+ of local storage. Therefore, I would want to keep local backups and copy to the gateway cache as needed to transport to the cloud. Maybe with the Amazon appliance, I could use all 100TB+ of my local storage as the local cache and not pay a licensing fee and also keep the .vbk's, .vrb's, vib's in their native format. The riverbed parses the backup files into it's own native format as part of it's dedup/compression.