Veeam Cloud Connect - Acceptable Risk V's Retention

[Berniebgf]

Hi All,

Veeam Cloud Connect is now "in play" and we (as a partner) have been evaluating its functionality and our intended "Cloud Backup" solution strategy.
During these discussions we have a common question, this question is driven by the follow;

1. In Australia it can be challenging / expensive to obtain appropriate WAN link performance to move the volume of data for "full backups" in an appropriate time frame.
2. Veeam "Cloud backup" offers three cloud backup options for clients, Reverse incremental, Incremental forever and Incremental with synthetic / active full.
3. The Veeam Cloud Connect component is NOT a proxy, it is just a repository so there is no "local processing" of synthetic fulls (this is my understanding).

In reality most customer will likely be limited to Incremental forever for their cloud backups, with an initial seed..... (Reverse incremental to Cloud???? how will this be processed? across the WAN link?)

So the questions is;
What is the acceptable number of recovery points that you would be willing to have with Incremental Forever in a Cloud Backup Solution with no "scheduled" synthetic / active full?

Are customers looking for "Long Term" retention for their offsite cloud backup in most cases? ( I believe so).
Interested to hear people thoughts.

Thanks

Bernie.

[Gostev]

Actually, Backup Copy job is designed to be forever incremental with no periodic fulls, thus the reason for its built-in backup health check feature. This is not specific to Cloud Connect though, we've had this feature since v7. Thanks!

[veremin]

Reverse incremental to Cloud???? how will this be processed? across the WAN link?

Instead of reversed incremental mode, you'd better stick to forward incremental forever backup, since it essentially does the same things but at the cost of less I/O. Thanks.

[foggy]

3. The Veeam Cloud Connect component is NOT a proxy, it is just a repository so there is no "local processing" of synthetic fulls (this is my understanding).

In fact synthetic activity will be performed locally, since the repository is either agent-enabled (meaning it has Veeam data mover agent installed on it) Windows or Linux-type repository or uses Veeam B&R console as a proxying server (CIFS-type repository).

[Gostev]

Instead of reversed incremental mode, you'd better stick to forward incremental forever backup, since it essentially does the same things but at the cost of less I/O. Thanks.

Sounds like you are talking about primary backup job here. However I don't expect to see customers using that with Cloud Connect normally, since local backup is a must for most scenarios (which leaves us with Backup Copy jobs to Cloud Connect repository).

[Berniebgf]

In fact synthetic activity will be performed locally, since the repository is either agent-enabled (meaning it has Veeam data mover agent installed on it) Windows or Linux-type repository or uses Veeam B&R console as a proxying server (CIFS-type repository).

Thanks for the responses all,

foggy, can you clarify the point about? when you say "locally" are you talking about the "client side" or the "cloud provider" side?

Does the Cloud Connect infrastructure process synthetic fulls?

regards

Bernard

[Gostev]

Provider side.

Cloud Connect infrastructure does not process backups at all. In fact, it does nothing except virtualizing all traffic between proxy and repository into a single port and adding multi-tenancy on top of a single backup repository. The entire architecture is still the same: proxy, repository and all Veeam functionality (like repository-side synthetic fulls) is unaffected by Cloud Connect presence. It is just that you no longer need to maintain VPN and individual backup repository per user.

If you have more questions about service provider side of Cloud Connect, please apply for Veeam Cloud Provider group to get access to the dedicated forum for service providers (we want to keep these discussions separate, not to confuse end users).

[veremin]

Sounds like you are talking about primary backup job here. However I don't expect to see customers using that with Cloud Connect normally, since local backup is a must for most scenarios (which leaves us with Backup Copy jobs to Ccoud Connect repository).

The expected use case is customer's backup copy jobs pointed to cloud repositories. However, the question number two (about choosing among available backup modes - rever, forever incremental, forward+synt/full) made me think the OP was talking about backup job.