actually best practice is always to have a local backup to allow for fast backup and restore times. From here, using backup copy jobs you can store additional copies to a service provider offering Cloud Connect. This gives you faster backup (storing data locally is faster than doing it over wan, so backup completes faster and VM snapshots stay open for less time), and restores are also faster as source is local and are not impacted for example by lack of internet connection.
dellock6 wrote:This said:
1) doesn't matter, as backup copy jobs are always forever forward incremental
**) No idea where this comes from, Cloud Connect doesn't simply copy backup files, it uses backup copy to create synthetic backups at a secondary location. Yes it's possible to send primary backup jobs to Cloud Connect, but we highly suggest not to do it, again for the reasons explained before.
bitterloa wrote:I already have a local backup job successfully running. It is using Reverse Incremental mode which is working great--however as I understand it, it would be terrible to try and push (or use a backup copy job) to copy a Reverse Incremental backup to cloud storage. This is because, although Reverse Incrementals are great for *local* storage, the copy job would have to push the complete/full backup over the WAN every day since it's this big file that is updated every time for Reverse Incremental. Please correct me if I'm wrong, but this is my understanding
Because man I'm pretty sure back in the day, like v7 "Cloud Connect" was only copying the .vbk files to the cloud, like a file copy only. Looks like this has changed drastically in recent versions (a good thing) but may explain the discrepancy of our understanding.
Ok, just to be sure here -- what you are saying is that Backup Copy jobs don't just simply copy the whole full backup to the cloud every time a new full is created locally--rather it will create a Synthetic Full backup with the full and subsequent incrementals already stored in the cloud? Because in a Forever Forward Incr. the "big" full backup is constantly updated locally once the retention policy is reached. Meaning the local *full* backup is changed/updated every day. So if this local/full is updated every day, then what your saying is that performing a Backup Copy of this job will *not* push this big ass file over the WAN every day, rather it will use some magic sauce and reconstruct the offsite full backup via Synthetic Full?
The new Veeam Cloud Connect seems to be 1000x better than v7's 'cloud edition'.
But it would be awesome if really it doesn't matter--that if Reverse Inc.
Users browsing this forum: BLWL, Google [Bot], Google Feedfetcher and 1 guest