Is their a best practice on how archiving to cloud storage should be configured

Question

Is there any kind of best practice on how Dell envisage archive to cloud to be used; we are struggling to get our heads around it is designed to work. Archiving works ok for creating point in time snapshots of entire recovery chains to HDD for archival but that doesn't work too well when you storage is in the cloud as pushing TB of data around from the core isn't practical... on the other hand if you enable archive to the cloud incrementally you end up with every single recovery point saved as far as I can work out. What is the best way to say do the following (lets say as an example a 1TB machine with 10GB per day disk write, say 75% hitting the same files repeatedly several times a day over a week - thus the roll up removes the surplus intermediate points) 
 The RPO want to look like this 
 
 1 recovery point per hour 
 after a week roll up to daily 
 after 3 months roll up to weekly 
 after 6 months roll up to monthly 
 ^^^ this bit with the rollups works fine ^^^ 
 then archive the monthly snapshot to the cloud for cheap long term retention 
 and remove oldest monthly snapshot from expensive local storage 
 
 I am not wanting every hourly recovery point into the cloud for ever more, that will be prohibitively expensive, only the monthly snapshots at 6 months old; and I don't want to be uploading a new full 1TB base image per month if it can be helped but as far as I can tell that is what will need to happen as having removed the oldest snapshot you will roll up into a new base image at the oldest point.

Carol.Buckley · Answer

Hi Chris, I checked with one of our senior engineers on this: 
 
We have the perfect recommendation for sending some data to the cloud but not all: the Rapid Recovery Replication Target VM in Azure. You can send the data you want to the cloud via replication and customize the retention policy. Then you can archive directly from the VM; as it is Azure to Azure data transfer it is faster and free. So a proposed solution based on your RPO would be as follows: 
 
•	On the local Core: 
o	1 recovery point per hour 
o	after a week roll up to daily 
o	after 3 months roll up to weekly 
 
•	On both the local core and on the replication target: 
o	after 6 months roll up to monthly 
	Replicate this to the Azure target core by setting the retention policy accordingly 
 
•	On the Azure Replication target set the archive settings and retention policy to match: 
o	then archive the monthly snapshot to the cloud for cheap long term retention 
o	and remove oldest monthly snapshot from expensive local storage 
What this does is give you the retention that you are looking for plus redundancy. Couple with the cost benefit of being able to select a small instance size in Azure. 
 
Regarding best practices for the Rapid Recovery replication target VM in Azure, general Rapid Recovery best practices would apply. 
 
Best practices for BU/archiving: It’s better to keep longer retentions in the cloud than keeping them onsite. For cost considerations, you could use the Rapid Recovery Cloud Connector capability and the archive to cloud feature. This type of storage is cheaper and still offers the ability to recover data at the file level. 
 
ROI relative to data footprint is difficult to pinpoint, because ROI is dependent on use factors and cost. If you’re archiving from on premises to cloud directly, your ROI is easier to achieve. However, without a Rapid Recovery core in the cloud or on prem, you would not be able to recover. (In the event that the primary core was lost as in Godzilla coming and destroying the building) The combination of archive to cloud, on premises colo, and Rapid Recovery cores in Azure will give you the best possible RPO and RTO. One could argue that this peace of mind and protection is a good ROI. 
 
Best wishes, 
 
Carol