This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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.

Parents
  • Chris:

    In an attempt to add to the conversation, please find below my "tuppence" re archiving issue.

    It is my understanding that you want to archive monthly recovery points only. Within some constraints this may be possible. I would try using the manual archiving option with the incremental recycle action and choose the recovery point for the month you want to archive. (see pictures below)

     Since due to rollups you have only one recovery point for the target month, since you are doing an incremental archive and since the repair orphans option is checked, this should work. On the less promising side, the archive size may be higher than you expect due to the metadata needed to keep the data consistent but anyway, you get a better deal than archiving every single recovery point.

    Now, on the theory side,

    Rapid Recovery works in recovery chains, which are composed of a base image and incrementals. In order to access a  point in time backup, you need to mount the corresponding recovery point. This means that all the recovery points down to the base image need to be participate in the process of recreating recreate the volume image corresponding to the desire recovery point. Goes without saying that the rollup process consolidates the recovery points in line with the retention policy.
    As such, you cannot have discrete recovery points unless they are base images (which in turn are recovery chains of zero length).
     
    In practical terms, your archive will have at least one base image, one incremental for each month and some additional data to preserve consistency. We cannot really predict which this additional data (which includes metadata and whatever other data is needed) will be. For instance, if you take a base image on one of your machines, the previous recovery chain will be interrupted and the archive will include, necessarily the new base image (as processed as it may be during the rollup process).
     
    Hope that this helps. Please let me know.
     
Reply
  • Chris:

    In an attempt to add to the conversation, please find below my "tuppence" re archiving issue.

    It is my understanding that you want to archive monthly recovery points only. Within some constraints this may be possible. I would try using the manual archiving option with the incremental recycle action and choose the recovery point for the month you want to archive. (see pictures below)

     Since due to rollups you have only one recovery point for the target month, since you are doing an incremental archive and since the repair orphans option is checked, this should work. On the less promising side, the archive size may be higher than you expect due to the metadata needed to keep the data consistent but anyway, you get a better deal than archiving every single recovery point.

    Now, on the theory side,

    Rapid Recovery works in recovery chains, which are composed of a base image and incrementals. In order to access a  point in time backup, you need to mount the corresponding recovery point. This means that all the recovery points down to the base image need to be participate in the process of recreating recreate the volume image corresponding to the desire recovery point. Goes without saying that the rollup process consolidates the recovery points in line with the retention policy.
    As such, you cannot have discrete recovery points unless they are base images (which in turn are recovery chains of zero length).
     
    In practical terms, your archive will have at least one base image, one incremental for each month and some additional data to preserve consistency. We cannot really predict which this additional data (which includes metadata and whatever other data is needed) will be. For instance, if you take a base image on one of your machines, the previous recovery chain will be interrupted and the archive will include, necessarily the new base image (as processed as it may be during the rollup process).
     
    Hope that this helps. Please let me know.
     
Children
No Data