With the cloud update scheduled for November 2017, Phoenix introduces backup sets to help you manage the server data backups effectively. This article helps you understand the transition from the current configuration workflow to the new workflow for backup sets.
With this upgrade, there will be no change in your existing settings, such as the backup content, schedule, and retention period. The upgrade repackages the existing backup policy and retention policy into different entities, such as content rule and backup policy for better usability and flexibility. To use all the features of backup sets, you must upgrade to Phoenix agent version 4.7. Druva will share the link and details to the latest version at the time of the release.
For a quick demo of backup sets, check this video.
Current workflow for configuring backup
In the current backup configuration workflow, the storage, backup policy, and retention policy are associated with a server group, an access-control entity. The configuration workflow consists of the following:
Backup policy: The settings for the backup content, backup schedule, pre and post script settings (File server), and other advanced settings, such as automatic retry, smart scan (File server), and so on.
New workflow for configuring backup with backup sets
In the new workflow, the storage, backup policy, and retention period are associated with a backup set and not a server group. You have to attach the registered server to an administrative group and define one or more backup sets for the server. The configuration workflow consists of the following:
- Administrative group: Server groups will be renamed to administrative groups. Unlike server groups, administrative groups are just a logical categorization of servers for better management.
- Backup set:
- Storage: The Phoenix storage where data from your servers is backed up.
- Backup content: The data that is selected for backup, such as files and folders, and databases. You can define the backup content with a content rule or custom content. It is a distinct entity of a backup set.
- Backup policy: The configuration of backup schedule, retention period, pre and post script settings (File server), and other advanced settings, such as automatic retry, and smart scan (File server). The retention policy in this workflow is clubbed with the backup policy.
What’s changed for each entity
Let’s take a look at what will happen to your existing entities with the release of backup sets:
- Server groups vs. Administrative groups: All the existing server groups will be renamed to administrative groups. There will be no change in the naming convention. However, administrative groups will only logically categorize servers for better management. You can view the list of existing server groups under Manage > Administrative Groups.
- Backup and Retention policies:
- The retention policy attached to the server group will be clubbed with the backup policy that will be attached to an individual backup set. You can now configure backup set with different backup policy or content rule that belong to the same administrative group.
- Backup policy and retention policy attached to a server group will be renamed as <Existing backup policy>_<Existing retention policy>.
For example: If your existing backup policy name is x, and the existing retention policy name is y, then the new backup policy name will be x_y.
- Backup content will be moved out of backup policy and saved as a distinct entity called as the content rule.
- If a retention policy is not attached to any server group, it will be deleted.
- If a backup policy is not attached to any server group:
- The backup policy name will be retained.
- The default retention settings will be applied to the policy.
- The backup content will be saved as a content rule for the File server. For more information about the naming convention of the content rule, see Naming conventions for content rule.
- The backup content will be deleted for the MS-SQL server.
- If a backup policy is attached to different server groups and the server groups are associated with different retention policies, the number of backup policies that are created will be based on the combination of backup policy and retention policies. Here’s an example scenario to illustrate the combination:
- A backup policy BP is associated with two server groups, SG1 and SG2.
- A retention policy RP1 is attached to the server group SG1.
- A retention policy RP2 is attached to the server group SG2.
- After the upgrade, two sets of backup policies will be created, BP_RP1 and BP_RP2.
- Backup content:
- The backup content will be moved out of backup policy and saved as a distinct entity.
- For the File server, the content rules will be created from the existing backup policies. All the content rules for your servers are listed on the Phoenix Management Console under Manage > Content Rules. All your content rule names will be prefixed with Rule_.
- If a backup policy is attached to a server group, the content rule name will be created as follows:
For the File server, all your content rule names will be derived from the backup content.
Existing content in backup policy
Derived content rule name
Note: As the “Rule_E_Projects” content rule already exists, the content rule name will be appended by 1.
For MS-SQL server, the databases listed under the Exclude Databases section will be a part of the custom content.
- Storage: The storage attached to the server group during the server configuration gets mapped to the backup set. You can view the storage associated with the backup set under the Backup Configuration section on the Servers details page.
- CloudCache: The existing CloudCache configuration is moved from the server group to an individual backup set. This includes the Cache Retention setting.