The backbone of the CPM solution is the backup policy. A backup policy defines everything about a logical group of backed-up objects. A policy defines:
- What will be backed up – Backup Targets.
- How many generations of backup data to keep.
- When to back up – Schedules.
- Whether to use backup scripts.
- Whether VSS is activated (Windows Servers 2008, 2012, and 2016 only).
- Whether backup is performed via a backup agent (Windows only).
- The retry policy in case of failure.
- DR settings for the policy.
The following sections explain the stages for defining a policy.
- Schedules are the objects defining when to perform a backup.
- Schedules are defined separately from policies.
- One schedule can be associated with several policies.
- Multiple schedules can be associated with the same policy.
All backup times are derived from the start time.
To define a schedule:
- In the main screen, click the Schedules tab and then click New Schedule.
- Type a name for the schedule and an optional description.
- In the Repeats Every list, select the frequency of the backups for this schedule. The possible units are months, weeks, days, hours, and minutes.
- In the Start Time list, select the schedule start time.
- If you want a daily backup to run at 10:00 AM, set Repeats Every to one day and the start time to 10:00 AM.
- If you want an hourly backup to run at 17 minutes after the hour, set Repeats Every to one hour and the start time to XX:17.
- The date can also be set. The default is the current day.
- Important: For weekly or monthly backups, the start time will determine the day of week of the backup schedule and not the days of week check boxes.
- In the End Time list, select when the schedule will expire. By default, it is never. Furthermore, you can define which weekdays the schedule will be active on.
- For the root/admin user, if you have created additional managed users, select the user to whom the schedule belongs.
Ad-hoc backups are initiated in the Policies tab. See section 4.2.6.
When you configure a CPM server, its time zone is set (see section 2.3). All time values which are shown in CPM’s management application are in the time zone of the CPM server.
Important: Even when you are backing up instances that are in different time zones, the scheduled backup time is always according to the CPM server’s local time.
In CPM’s database, times are saved in UTC time zone (Greenwich). So, if, at a later stage, you start a new CPM server instance, configure it to a different time zone, and use the same CPM data volume as before, it will still perform backup at the same times as before.
After defining a schedule, you can set specific times when the schedule should not start a backup. For example, you want backup to run every hour, but not on Tuesdays between 01:00 PM and 3:00 PM. You can define that on Tuesdays, between these hours, the schedule is disabled.
To define disabled times:
- In the Disabled Times in Day column of the Schedules tab, click the Configure button.
- As shown in Figure 4‑1, add, edit, or remove multiple disabled times.
You can define a disabled time where the finish time is earlier than the start time. The meaning of disabling the schedule on Monday between 17:00 and 8:00 is that it will be disabled every Monday at 17:00 until the next day at 8:00. The meaning of disabling the schedule for All days between 18:00 and 6:00 will be that every day the schedule will be disabled after 18:00 until 6:00.
Beware not to create contradictions within a schedule’s definition:
- It is possible to define a schedule that will never start backups.
- You can define a weekly schedule which runs on Mondays, and then deselect Monday from the weekdays.
- It is also possible to create different “disabled times”, which would effectively mean that the schedule is always disabled.
Policies are the main objects defining backups. A policy defines:
- What to back up
- How to back it up
- When to perform the backup (by associating schedules to the policy)
Creating a New Policy
To define a new policy:
- Go to the Policies tab and click New Policy. The Policy window opens.
- In the Name box, type a name for the policy.
- For the root/admin user, if you have created additional managed users, select the policy owner in the User box.
- If you have more than one account, in the Account list, select the account that the policy is associated with. The account cannot be modified after the policy has been created.
- In the Auto Target Removal list, specify whether to automatically remove resources that no longer exist. If you enable this removal, if an instance is terminated, or an EBS volume deleted, the next backup will detect that and remove it from the policy. Choose yes and alert if you want the backup log to include a warning about such a removal.
- In the Generations to Save list, select the number of backups to keep for this policy. Older backups will be automatically deleted by CPM.
- If you define a daily backup and leave the value of Generations to Save at 30, this will give you the ability to recover from backups up to 30 days ago.
- If you define an hourly backup, this will give you the ability to recover from backups up to 30 hours ago.
- To keep the records of backup activity beyond the number of days covered by the Generations to Save, see section 8.4.
- In the Description box, optionally type a description.
Note: As a user, you need to balance the amount of time you want to be able to go back and recover from Recovery Point Objective (RPO), and the cost of keeping more snapshots. Sometimes you will want to trade off the frequency of backups, and the number of generations. Consider what best suits your needs.
Click Apply. The new policy is included in the list of policies in the Policies tab.
In the case of EC2 instances, you can set options for any instance.
To configure an instance:
- Select a policy.
- In the Backup Targets screen, select an instance.
- Click Configure.
In the Which volumes list, choose whether to back up all the volumes attached to this instance, or include or exclude some of them. By default, CPM will back-up all the attached storage of the instance, including volumes that are added over time.
In the Backup Options list, choose whether to:
- Take only snapshots (the default for Linux-based instances)
- Take an initial AMI and then snapshots (the default for Windows-based instances)
- Just schedule AMI creation
Backup targets define what a policy is going to back up. You define backup targets by clicking the Backup Targets button of a policy in the Policies tab. You have multiple types of backup targets:
- Instances – This is the most common type. You can choose as many instances as you wish for a policy up to your license limit.
For each instance, allowed under your license, define:
- Whether to back up all its attached volumes, some, or none.
- Whether to take snapshots (default for Linux), take snapshots with one initial AMI (default for Windows), or just create AMIs.
- EBS Volumes – If you wish to back up volumes, not depending on the instance they are attached to, you can choose volumes directly. This can be useful for backing up volumes that may be detached part of the time or moved around between instances (e.g. cluster volumes).
- RDS Databases – You can use CPM to back up RDS databases using snapshots. There are advantages with using the automatic backup AWS offers. However, if you need to use snapshots to back up RDS, or if you need to back up databases in sync with instances, this option may be useful.
- Aurora Clusters – Even though Aurora is part of the RDS service, Aurora is defined in clusters rather than in instances. Use this type of backup target for your Aurora clusters.
Aurora cluster storage is calculated in increments of 10 GiB with the respect to the license. For example, if you have over 10 GiB of data but less than 20 GiB, your data is computed as 20 GiB.
Keep in mind that clusters can grow dynamically and may reach the storage limits of your license. If the total storage is approaching your license limit, CPM will issue a warning.
- Redshift Clusters – You can use CPM to back up Redshift clusters. Similar to RDS, there is an automatic backup function available, but using snapshots can give an extra layer of protection.
- DynamoDB Tables – You can use CPM to back up DynamoDB tables. The recommended best practice is a backup limit of 10 DynamoDB tables per policy.
When defining your backup targets, keep in mind that DynamoDB table storage is calculated in increments of 10 GiB with the respect to the license. For example, if you have over 10 GiB of data but less than 20 GiB, your data is computed as 20 GiB.
Tables can grow dynamically and may reach the storage limits of your license. If the total storage is approaching your license limit, CPM will issue a warning.
From the Backup Targets screen, click the relevant Add button to add backup targets of the resource type to the policy:
- When adding backup targets, you will see all the backup targets of the requested type that reside in the current region, except the ones already in the policy.
- You can select another region to see the objects in it.
- If there are many objects, you have the ability to filter, sort, or browse between pages.
- For each backup target, you can see the number of policies it is already in (Policies column). If the number is larger than zero, click it to see which policies it is in. See Figure 4‑3.
To add a backup target to the policy:
- Select the Add check box of the target, or targets.
- Click Add Selected. The selected objects are added to the policy’s backup target list.
- Repeat as many times as needed.
- Click Close when finished.
If you choose to just create AMIs:
- CPM will create AMIs for that instance instead of taking direct snapshots. App-aware backup per agent does not apply for AMI creation.
- You can choose whether to reboot the instance during AMI creation or not to reboot, which leaves a risk of a data corruption. As opposed to AMI creation in the EC2 console, the default in CPM is no reboot.
Note: Try not to schedule AMI creations of an instance in one policy, while another policy running at the same time backs up the same instance using snapshots. This will cause the AMI creation to fail. CPM will overcome this issue by scheduling a retry, which will usually succeed. However, it is recommended to avoid such scheduling conflicts.
Single or Initial AMIs are meant to be used mainly for Windows instance recovery.
CPM will keep a single AMI for each instance with this setting. A single AMI will contain only the root device (boot disk).
CPM will rotate single AMIs from time to time. It will create a new AMI and delete the old one. CPM aims to optimize cost by not leaving very old snapshots in your AWS account.
By default, CPM will rotate single AMIs every 90 days. That value can be configured in the Cleanup section of the General Settings screen to any number of days, or to 0, if you prefer no rotation at all.
Limitations with AMI creation:
AMIs will be copied across region for DR, but they will not be copied across accounts.
Important: If you use cross-account backup, be aware that if you need to recover the instance at the remote account, you need to make sure you have an AMI ready in that account.
Note: If you move a backup into the Freezer (see section 8.3), initial AMIs will not move with it, so make sure you have an AMI ready. If the original policy exists, you can grab the AMI ID from the snapshot list of one of the backups of the policy.
To see more policy options, click More Options for a policy in the Policies tab. Backup scripts refers to those running on the CPM server (see section 7):
Linux Backup Scripts – This option is turned off by default. Change to Activated to activate backup scripts.
Scripts Timeout – Timeout (in seconds) to let each script run. When a backup script runs, after the timeout period, it will be killed, and a failure will be assumed. The default is 30 seconds.
Scripts Output – CPM can collect the output of backup scripts to the standard error (stderr). This may be useful for debugging. It can also be used by a script to log the operations it is performing and write useful information. This output is captured, saved in the CPM database, and can be viewed from the Recovery Panel screen. To turn this option on, choose Collect. The default option is Ignore.
Note: The output of a script is typically a few lines. However, if it gets really big (MBs), it can affect the performance of CPM. If it gets even larger, it can cause crashes in CPM processes. To avoid the risk of too much data going to stderr, redirect the output elsewhere.
Backup is Successful when – This indicates whether a backup needs its scripts/VSS to complete, in order to be considered a valid backup. This has a double effect:
For retries, a successful backup will not result in a retry;
For the automatic retention management process, a backup which is considered successful is counted as a valid generation of data.
The possible values are:
it finishes with no Issues – If scripts and/or VSS are defined for this policy, the backup will be considered successful only if everything succeeds. If backup scripts or VSS fails and all snapshots succeed, the backup is not considered successful. You can still recover from it, but it will cause a retry (if any are defined), and the automatic retention management process will not count it as a valid generation of data. This is the stricter option and is also the default.
snapshots succeed. Even if scripts or VSS fail – This is the less strict option and can be useful if scripts or VSS fail often, which can happen in a complex environment. Choosing this option accepts the assumption that most applications will recover correctly even from a crash-consistent backup.
Retry information – The last three options deal with what to do when a backup does not succeed:
Number of Retries – The maximal number of retries that can be run for each failed backup. The default is three. After the retries, the backup will run again at the next scheduled time.
Wait between Retries – Determines how much time CPM will wait after a failure before retrying. Backup scripts and VSS may sometimes fail or timeout because the system is busy. In this case, it makes sense to substantially extend the waiting time until the next retry when the system may be more responsive.
Number of Failures to Trigger Alert – The minimum number of failures to trigger an alert.
An ad-hoc backup will execute the selected Policy and create backups of all its targets.
Note: An ad-hoc backup counts as another generation if it completes successfully.
To run a backup immediately:
- In the main screen, click the Policies tab.
- To add a backup target to a policy, click Backup Targets in its Configure column. See section 4.2.2.
- In the Operations column for the policy, click run ASAP.
- To follow the progress of the backup, click the Backup Monitor tab. Open the log to view backup details.