The CPM Server runs in a VPC, except in old environments utilizing EC2 Classic. For CPM to work correctly, it will need outbound connectivity to the Internet. To use AWS endpoints, see AWS Regions and Endpoints.
You will need to provide such connectivity using one of the following methods:
- Attaching an elastic IP,
- Using a dynamic public IP, which is not recommended unless there is a dynamic DNS in place,
- Enabling a NAT configuration, or
- Using a proxy
You will need to access it using HTTPS to manage it and possibly SSH as well, so some inward access will need to be enabled.
If you will run Linux backup scripts on it, it will also need network access to the backed-up instances.
If CPM backup agents will need to connect, they will need access to it (HTTPS) as well.
If backup scripts are enabled for a Linux backed-up instance, it will need to be able to get an inbound connection from the CPM Server.
If a Thin Backup Agent is used in a Windows backed-up instance, the agent will need outbound connectivity to the CPM Server.
CPM continues to back up instances even if they are stopped. This may have important implications:
If the policy has backup scripts and they try to connect to the instance, they will fail, and the backup will have Backup Partially Successful status.
If the policy has no backup scripts and VSS is not configured, or if the policy’s options indicate that Backup Partially Successful is considered successful (see section 4.2.3), backup can continue running, and automatic retention will delete older backups. Every new backup will be considered a valid backup generation.
Snapshots will soon take no storage space since there will be no changes in the volumes, and EBS snapshots are incremental.
Assuming the instance was shut down in an orderly manner and did not crash, backups will be consistent by definition.
Note: It is recommended that if you are aware of an instance that will be stopped for a while, you disable the policy by clicking its name and changing status to disabled.
Another way to proceed is to make sure the policy is not entirely successful when the instance is stopped by using backup scripts, and to keep the default stricter option that treats script failure as a policy failure. This will make sure that the older generations of the policy, before it was stopped, will not be deleted.
Important: If you disable a policy, you need to be aware that this policy will not perform backup until it is enabled again. If you disable it when an instance is stopped, make sure you enable it again when you need the backup to resume.
Backups belonging to a policy eventually get deleted. Every policy has its number of generations, and the retention management process automatically deletes older backups.
To keep a backup indefinitely and make sure it is not deleted, move it to the Freezer. There can be several reasons to freeze a backup:
- An important backup of an instance you already recovered from so you will be able to recover the same instance again if needed.
- A backup of interest, such as the first backup after a major change in the system or after an important update.
- You want to delete a policy and only keep one or two backups for future needs.
To move a backup to the Freezer:
- In the Backup Monitor tab of the main screen, select the backup and click Move to Freezer.
- Type a unique name and an optional description. You can later search and filter frozen backups using as keywords the name or description.
- After a backup is in the Freezer:
It will only be deleted if you do so explicitly.
It will still remain even if you delete the whole policy, frozen backups from the policy will still remain.
It is recovered the same way as from a regular backup.
Automatic Cleanup allows you to manage the frequency of the cleanup process and the:
- Number of days to keep backup record, even if the backup is deleted.
- Number of days after which to rotate single AMIs.
Note: Keeping backups for long periods of time can cause the CPM database to grow and therefore affect the size you need to allocate for CPM’s data volume. N2W Software estimates that every GiB will accommodate the backup of 10 instances. N2W Software estimates that 10 instances are correct when every record is kept for around 30 days. If you want to keep records for 90 days, triple the estimate, i.e. for 10 instances make the estimate 3 GiB, for 20 make the estimate 6 GiB, etc.
To manage the number of generations saved:
- In the General Settings tab, select Cleanup.
- In the Cleanup interval list, select the number of hours between cleanup runs. Click Run Now to start a cleanup immediately.
In each list, select the number of days to:
- Rotate single AMIs
- Keep deleted records
- Keep user audit logs
Note: The number of days is counted since the backup was created and not deleted. If you want to make sure every backup record is saved for 90 days after creation, even if it was already deleted, select 90.
Backing up independent volumes in a policy is performed regardless of the volumes attachment state. A volume can be attached to any instance or not attached at all, and the policy will still back it up. Backup scripts can determine which instance is the active node of a cluster and perform application quiescence through it.