In CDSB, backup is a job-driven process. To perform backup, you need to configure backup jobs. A backup job defines when, what, how and where to back up AWS objects, such as instances and volumes. One backup job can be used to process one or several objects. Backup jobs can be started automatically by schedule, run once immediately or with a delayed start.
To create a job, go to the Jobs tab and press the Create Job button. The Job wizard will display.
As you create a backup job and add objects, such as instances and volumes, as well as take advantage of other configurable options, you will notice that in the upper right corner of the user interface, you can see the job’s estimated cost displayed that will change as you add or remove objects and set the backup job’s configuration. The estimated AWS storage cost displayed will be calculated in real time depending on the parameters you set within the job. The following parameters are taken into account for cost calculation:
•Job schedule;
•Job objects snapshot sizes;
•Retention policy;
•Replication options.
Please note that if you hover your mouse pointer above the blue information icon immediately following the estimated cost, a more thorough breakdown is displayed of the backup job’s estimated cost. Specify a job name, tenant (Administrator by default) and job description. As an example case, we need to create a job running every night at 3:00 AM.
Select the objects you need to backup. Every job can contain many objects of different types: Instances, Volumes, RDS databases, DynamoDB tables, FSx, Hyper-V Virtual Machines, ESXi Virtual Machines, Aurora and Redshift clusters.
As an alternative to adding instances or volumes to the job explicitly, you can provide conditions for tags. Tags are simple labels that you create and add to your backup jobs, making it easier to search, manage and filter resources based on the purpose, environment or other criteria you designate and easily recognize. Cloud Daddy automatically uses the AWS tags you have provided with newly created backup jobs providing an effortless and streamlined experience in managing backup. For example, let us add all objects that have Department = Marketing and OS = Windows to this job. It is very convenient as object tags are scanned every time when the job is running. So, if you add a new instance in the future with the same tags after the job is created, it will be added to the job automatically during future backup.
At the next step, specify job-scheduling options.
You can create any schedule you want: select exact days of the week, workdays, days of the month and so on.
It is possible to specify the denied intervals for periodic schedules by pressing Periods button. For example, you can set a backup job to run every hour, but not on weekdays between 08:15 AM and 8:15 PM.
You need to be attentive not to define a schedule that will never trigger backups.
If necessary for disaster recovery (DR) purposes, you can replicate your backups to other regions/accounts and to Microsoft Azure. You do not have to replicate every backup; you even can replicate every 10th backup, for example.
If necessary, define scripts. Scripts can be very beneficial and can be used for many different purposes, including the creation of application consistent backups in a Linux environment when Volume Shadow Copy Service (VSS) is not available.
Scripts can be run in the following cases:
•Before backup;
•After backup start;
•After backup is complete.
There are two types of scripts:
•PowerShell – used mainly for Windows instances;
•Shell – used for Linux instances.
Scripts can be run one after another and users can determine the sequence in which they run.
Scripts can also be executed on individual instances. You can configure this in the “Objects tab” by selecting an instance and pressing the Options button.
Scripts can be created and edited in the Scripts tab within the Settings module.
The Other Settings tab includes various options of a backup job.
First, you have the option to set a retention policy which controls the amount of AWS storage space used by your backups and can regulate your monthly AWS storage cost. You can set the period during which backups are available and the number of restore points to keep. Old backups that do not correspond to the set retention parameters can be either completely removed or archived to cheaper Amazon S3 Glacier storage, using the Retention Mode setting of “Archive old backups to S3”. Please note that there are additional costs related to the storage and transfer of data in S3/Glacier in comparison to removing old backups when setting the retention mode/policy.
CDSB uses its own proprietary incremental backup mechanism, which minimizes the space consumed by backups stored in Amazon S3.
A balance between storage price and recovery time can be configured within AWS using the Amazon S3 Console with the creation of a lifecycle rule for the S3 bucket used by CDSB.
The Backup Status Script Failed setting controls when a backup job is set to run scripts, whether an error in a script leads to an entire backup failure or to a warning.
The Instances Backup Mode setting controls AMI creation. By default, CDSB creates backups consisting of EBS snapshots for Linux instances and initial AMIs plus EBS snapshots for Windows instances.
CDSB stores an AMI for each instance and rotates AMIs per the configuration you have set within the General Settings to ensure a recent AMI copy is in place. CDSB creates new AMIs and deletes the old ones as a result of the newer copy being put in place. These AMIs are primarily used for Windows instance restores and other factors, since it is impossible to restore Windows instance root volumes from AWS snapshots.
If necessary, you can change the default backup mode to “AMI only”. “AMI only” backup mode provides the capability to create only an AMI of target Linux and Windows infrastructure objects as a result of a backup operation. Backups created with the “AMI only” mode consume additional storage, but can be desirable especially for Windows instances in accounting for root volumes and easier, faster recovery in case of disaster.
You can control and prohibit rebooting of Windows instances while an AMI is being created by selecting the “No Reboot” option. If you do not select this option, Windows Instances will be momentarily rebooted when AMIs are created and this ensures that everything on the instance is stopped and in a consistent state during the AMI creation process. If you are confident that your instance is in a consistent state appropriate for AMI creation, you can select the no reboot option.
If you enable application consistent backups, it means that Windows instances will be backed up by means of special procedure that will involve VSS-snapshot creation.
At the next step, you can review the job summary and run the job by pressing the Finish button.
The job status will be changed in a few seconds to “Running” and you can see that the backup is also being created in the Backups tab.