The backbone of the N2WS 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 of defining a policy.
Schedules are the objects defining when to perform a backup
Schedules are defined separately from policies and Scheduled Reports.
One or more schedules can be assigned to both policies and Scheduled Reports.
Schedules can be managed in the Schedules tab of the Home page.
Or, in the Schedules tab of the Reports button.
Note: Both interfaces include all defined schedules and the same definition options.
You can define schedules to:
Run for the first time at a date and time in the future.
Run forever or have a specific date and time to stop.
Repeat every ‘n’ minutes, hours, days, weeks, months.
Selectively enable for certain minutes, hours, and day of the week, but not for weeks and months.
Repeat every day of the week, or only run on certain days.
Exclude running the report during certain time ranges within the scheduled times.
For the root/admin user, if you have created additional managed users, you can select the user to whom the schedule belongs.
Important: For weekly or monthly backups and report generation, the start time will determine the day of the week of the schedule and not the days of week checkboxes.
The same schedules are used in backup operations and in generating Scheduled Reports. All times are derived from the start time, or the First Run time in the case of Scheduled Reports.
To define a schedule from the Home page:
- In the main screen, click the Schedules tab and 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 scheduled 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 default start date is the current date, but it can be changed to one in the future.
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.
In the Enabled on section, select the day-of-week checkboxes on which to run the schedule.
To set disabled times within the defined schedule, see section 4.1.3.
Ad-hoc backups are initiated in the Policies tab. See section 4.2.6.
To define a schedule from the Reports button:
- In the Reports page, select Schedules in the left pane and then click + New:
Type a name for the schedule and an optional description.
The First Run time is the start time for subsequent runs. Click Apply.
If you want a daily backup to run at 10:00 AM, set Repeats Every to one day and the First Run 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 First Run time to XX:17.
In the Expires box, click the calendar icon to select the date and time the schedule will expire. By default, the schedule never expires.
In the Repeat Every lists, select the frequency in the first list and the time unit from the second list. The possible units are months, weeks, days, hours, and minutes.
In the Enabled on section, choose the days of the week to run this schedule by selecting the relevant check boxes.
To exclude time ranges within the scheduled times, define disabled times. See section 4.1.3.
Ad-hoc generation of Scheduled Reports is initiated in the Reports page. See section 17.9.2.
When you configure an N2WS server, its time zone is set (see section 2.3). In the N2WS management application, all time values are in the time zone of the N2WS server.
Important: Even when you are backing up instances that are in different time zones, the scheduled backup time is always according to the N2WS server’s local time.
In N2WS’ database, times are saved in UTC time zone (Greenwich). So, if, at a later stage, you start a new N2WS 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 or generate a Scheduled Report. For example, you want a backup or report 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.
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.
Be careful not to create contradictions within a schedule’s definition:
It is possible to define a schedule that will never start backups or generate a report.
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.
To define disabled times from the Home page Schedules tab
- In the Disabled Times in Day column of the Schedules tab, click the Configure button for the target schedule.
- Add, edit, or delete multiple disabled times as needed, and click Apply.
Defining Disabled Times from the Reports Schedules Tab:
To define disabled times from the Reports page:
- In the Schedules tab of the Reports page, select a schedule and click Edit.
At the bottom of the page, turn on the Exclude Time Ranges toggle and click + New.
Define one or more time ranges for exclusion. Select the day of the week and the exclusion times in the Start Time and End Time lists. Click Apply after each definition.
Select the check boxes of the excluded time ranges to enable and click Save.
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
Note: As of v2.7.0, the ‘cpmdata’ policy is no longer using scripts as the default. Users can enable scripts by selecting Application Consistent for the cpmdata 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 N2WS.
- 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 9.4.
- For the cmpdata policy, to use scripts as the default, select Enabled in the Application Consistent list.
- In the Description box, optionally type a description.
- Click Apply. The new policy is included in the list of policies in the Policies tab.
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.
In the case of EC2 instances, you can set options for any instance.
By default, Copy to S3 is performed incrementally. In order to ensure the correctness of your data, you can force the copy of the full data for a single iteration to your S3 Repository. While defining the Backup Targets for a policy with Copy to S3, enable the Force a single full Copy option.
To configure an instance:
- Select a policy.
- In the Backup Targets screen, select an instance.
- Click Configure.Figure 4‑2
- 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, N2WS 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
- For Copy to S3, to have a full copy of the data copied to your S3 Repository, in the Force single full Copy list, select Yes.
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 N2WS 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 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, N2WS will issue a warning.
- Redshift Clusters – You can use N2WS 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 N2WS 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 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, N2WS will issue a warning.
Elastic File Systems (EFS) – You can use N2WS to back up and restore your EFS snapshot data to AWS using AWS Backup service.
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‑4.
To add a backup target to the policy:
- Select the Add checkbox 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:
N2WS 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 data corruption. As opposed to AMI creation in the EC2 console, the default in N2WS 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. N2WS will overcome this issue by scheduling a retry, which will usually succeed. However, it is recommended to avoid such scheduling conflicts.
220.127.116.11 Initial/Single AMI
Single or Initial AMIs are meant to be used mainly for Windows instance recovery.
N2WS will keep a single AMI for each instance with this setting. A single AMI will contain only the root device (boot disk).
N2WS will rotate single AMIs from time to time. It will create a new AMI and delete the old one. N2WS aims to optimize cost by not leaving very old snapshots in your AWS account.
By default, N2WS 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.
18.104.22.168 Limitations with AMI creation:
AMIs will be copied across regions 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.
To see more policy options, click More Options for a policy in the Policies tab. Backup scripts refer to those running on the N2WS 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 – N2WS 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 N2WS 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 N2WS. If it gets even larger, it can cause crashes in N2WS 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 N2WS 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.3.
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.