This article describes how rollup enforces the retention policy established for a protected machine.
When protecting your data using AppAssure 5, backup snapshots are taken frequently (according to the protection policy defined) and are saved to the repository specified by the Core. These recovery points are deduplicated before they are committed, and each represents the ability to restore the agent machine as of the point when the snapshot was taken. The more frequently an agent is backed up, the more granular the recovery point. Whether one agent or many are backed up to a Core, they proliferate quickly in the repository. To conserve resources over time, this data is then generally rolled up to an incrementally less granular series of recovery points. This article describes the retention policy and how it drives the rollup process.
When setting up a Core, administrators define a default retention policy. A retention policy is the set of business rules in AppAssure 5 that define the length of time the backup snapshots of protected machines are stored on the Core. It includes a primary setting, which indicates how long all snapshots should be retained in their original form. The retention policy also allows you to define up to five sets of rules that cause the system to “roll up” or combine backups into new recovery points that span a larger timeframe. For each of these rules, you establish the period of time (hour, day, week, month, year) for which a set of existing recovery points can be rolled up into a single recovery point. You also establish the retention period for that rule (in other words, how long that recovery point should persist before another rule applies, and the recovery point is merged with other recovery points spanning a larger period of time).
For information on best practices when considering defining a retention policy and planning rollup, see Best Practices for Rollup.
When adding each agent machine to protection by that Core, you can specify whether you want to apply the default policy for that Core, or customize a policy for a specific agent machine. For more information on applying the Core’s default retention policy, see How to Enable Rollup by Applying the Core Default Retention Policy to an Agent.
For more information on specifying a custom retention policy, see Customizing Retention Policy Settings for Agent Rollup.
Each recovery point persists in its original form in the repository for the retention period indicated in the primary setting of the retention policy (Keep all recovery points for [#] [time period]; for example, Keep all recovery points for 3 days).
When rollup runs, the system checks the age of each recovery point and the retention policy, and when specific recovery points are older than the time in the policy, discrete recovery points are rolled up.
Typically, rollup occurs during the nightly job, which by default is established at midnight. Your organization may change this setting. For more information on how to adjust the nightly job time, see the AppAssure 5 User Guide, Chapter 3, topic “Adjusting the Nightly Job Time.” This is also described in the KB article Best Practices for Rollup.
You can also force a rollup to occur at any time. When you force a rollup, the rollup that would otherwise occur during that day’s nightly job will be skipped (since the recovery points were already rolled up). For more information on forcing a rollup, see How to Force Rollup on an Agent Machine.
As data ages following the requirements defined in the retention policy, those recovery points are rolled up into fewer, less granular recovery points, until they “age out” when the age of the data is beyond the scope of the retention policy.
Using the following example protection schedule, for simplicity, snapshots are taken twice hourly on the agent machine. Without rollup, with 48 snapshots daily per agent, at the end of the seventh day there would be 336 recovery points for a single protected agent, 1,6808 for 5 protected agents, or 3,360 if 10 agents are set to back up to the Core.
This is where rollup comes into play. Enforcing the sample retention policy shown, all backups are taken twice hourly and maintained on the repository as-is for three days. During the nightly job after the third day, those recovery points are affected by the first rule, “keep 1 recovery point per hour for 2 days.” For a Core with one protected agent, the original recovery points taken twice hourly (which number 144 for three days) get rolled up into a single recovery point per hour, cutting that number in half. These 72 recovery points are retained for two days. (Meanwhile, the system continues to create new snapshots twice hourly until those recovery points reach the three-day threshold).
After the two-day retention period for the first rule passes, the next time the nightly job runs, the second rule is applied, “keep 1 recovery point per day for 4 days.” Thus, the 72 recovery points for the original three days are rolled up into 3 recovery points, one per day. Each allows the system to restore the agent to the state of the machine during the last hourly backup of that day. (Meanwhile, the system still takes new snapshots twice an hour, which are retained independently for three days, then rolled up into hourly backups for two days, then rolled up into daily recovery points for four days.)
Subsequent rollups will merge the recovery points we’ve been following with other recovery points. As the recovery points age, the rules in the retention policy are applied in sequence, with rollups occurring as appropriate during the nightly job. After the four-day retention period for the second rule passes, the third rule is applied to our original set of data, “keep 1 recovery point per week for 4 weeks.” Thus, the three recovery points (plus four more daily recovery points that have accrued subsequently) are rolled up into one recovery point. It allows the system to recover data as of the last hour in that week.
After 4 weeks, the fourth rule is applied, “keep 1 recovery point per month for 3 months,” and this data is merged with other data as a single monthly rollup, which is retained for 3 months. After that period, the fifth rule is applied, “keep 1 recovery point per year for 2 years.” Following the example set in this sample, each time the nightly job runs, data that is two years and one day old “ages out” and is no longer represented in a recovery point. That data is replaced with newer data being saved up to the two-year point.