How to upgrade Protector from a version prior to 6.0

Ops Center Protector Quick Start Guide

Version
7.9.x
Audience
anonymous
Part Number
MK-99PRT001-10
CAUTION:

Some features supported by your existing Protector 4.x or 5.x environment may not yet be supported by Protector 6.x. Ensure that you are fully aware of which features are not yet supported before upgrading.

ANY ATTEMPT TO UPGRADE WHEN USING AN UNSUPPORTED FEATURE WILL HAVE UNDEFINED CONSEQUENCES, INCLUDING POTENTIAL DATA LOSS.

The installer will warn about features that are unsupported before upgrading but will not detect if unsupported features are being used in your existing environment.

CAUTION:
Thin Image snapshot operations default to Provisioned using floating device. In versions prior to 6.5, this setting would automatically fallback to Fully provisioned if the hardware storage device did not support floating devices. With the introduction of Cascade mode snapshots in version 6.5 (now the default mode), this automatic fallback has been removed. Consequently:
  • Data flows created in versions prior to 6.5 that contain Thin Image snapshot operations, with cascade mode is enabled, will now fail if the underlying hardware does not support floating device. These data flows must be manually reconfigured to use the correct provisioning type. Please note that if these data flows also contain replication operations, then these will be re-evaluated when the modified data flows are re-activated.
  • Data flows created in versions prior to 6.5 that contain Thin Image snapshot operations, with cascade mode enabled, will now fail if the P-VOLs have any pre-existing non-cascade mode snapshots. If cascade mode is to remain enabled then any non-cascade mode snapshots must be deleted.
  • For data flows created in version 6.5 or later, if the hardware storage device on which Thin Image snapshot operations are performed does not support Floating device and Cascade mode, then Thin Image operations will fail, unless the appropriate settings are selected in the respective data flows.
  • Do not perform an upgrade while hardware replications are being paired. Wait for all pairings to complete.
  • Ensure that no Hitachi Block or File snapshots are mounted before upgrading.
  • Ensure that you have upgraded all nodes in your existing Protector environment to version 5.5.2 or later, following the supported upgrade path.
  • You must upgrade all available nodes to version 6.x before starting to use the 6.x environment; existing Client nodes will not be recognised by the upgraded 6.x Master.
  • Protector 6.x has improved, granular rules activation that allows rules to be activated for individual data flows without affecting existing rules for unrelated data flows. To take advantage of this, complex data flows should be refactored by splitting them into smaller individual flows. This is best done before upgrading because the Protector 6.x data flow editor has been designed to encourage the drawing of small, simple dataflows that can be managed independently.
  • If you have data flows in your existing environment that connect a source node to a destination node using both a Batch and Continuous mover in parallel, then these will still compile correctly. However you will need to redraw them as two separate flows (on the same or separate data flow diagrams) if you want to modify them. This is best done before upgrading. See the example below:

  • In previous versions it was possible to create a node group with mixed node types, although this would cause the rules compiler to generate an error. Protector 6.x enforces node groups containing nodes of the same type. Review your existing node groups to ensure that all member nodes are of the same type. This is best done before upgrading.

    When upgrading, the first node in a group is used to set the type of the group; any subsequent nodes that are of a different type are removed from the group. Warning logs are generated for any node which is removed from a group due to type mismatch.

  • In previous versions a separate repository store was created for each source node being backed up, the mover type and the store template used. In Protector 6.x a separate repository store is also created for each policy. When upgrading a data flow where a source node backs up to a repository using two or more policies over a single mover (e.g. two batch backup policies with different RPOs), Protector 6.x will create a new store in the repository so that there is one store for each policy.

    When the rules are reactivated after upgrading, the store holding the legacy backups will complete a fast incremental resynchronization, since it is already populated. The new store will complete a full initial synchronization, since it needs to be populated with data from the second policy. This full resynchronization may involve a significant amount of data transfer.

    When restoring, remember that any backups created after the upgrade from data flows, where a source node backs up to a repository using two or more policies over a single mover, will be located in new stores.

  • Legacy log messages cannot be viewed in Protector 6.x. If you need to refer to these messages after upgrading then export them prior to upgrade and view them in a text editor or spreadsheet. Ensure the log filters are set to their defaults so that all logs are exported. The export is limited to the last 25,000 log entries.
  • Legacy notification events cannot be ported across to Protector 6.x. Make a note of each notification event so that they can be manually reconfigured after the upgrade is performed.
  • Legacy versions of Protector made no distinction between Repositories and Hardware Storage Device proxies; in Protector 6.0 they are treated as separate entities. All legacy Repositories that were used solely for the purpose of acting as Hardware Storage Device proxies will be removed when upgrading.
  • Repositories and Hardware Storage Devices will rebuild their backup indices into a new database. This may take some time to complete, so restore points will not be listed immediately.
  • Protector 6.x no longer sets a retention on objects in HCP; it now deletes objects from HCP when they are no longer referenced by any snapshots in the repository from which they were tiered.

To upgrade Protector from a 5.5.2 or later environment to a 6.x environment:

  1. On the master node, run diagdata -f from a command prompt to preserve the current configuration and state files.
    These will be of use if for any reason the upgrade fails.
  2. Follow the procedure described in How to install/upgrade Protector on Windows and Linux or AIX or How to install a Protector master or client on a Windows cluster as appropriate.
    Push upgrade from the UI cannot be used; you must upgrade to Protector 6.x using the install wizard or command line. The installer will take you through the upgrade process.
  3. Once the upgrade process has been completed on all available nodes, log in to the Protector 6.x user interface.
  4. Reactivate all data flows simultaneously.
    CAUTION:
    You must initially reactivate ALL dataflows in one operation. If you do not, then any active block based replications that are not reactivated will be torn down.
    Your Protector environment will now be upgraded to Protector 6.x and will be implementing your existing data protection policies.
    Note:
    • The rules compiler will generate warnings where data flows and policies need to be amended to take advantage of new Protector 6.x features.
    • Some nodes may indicate that they are offline until after the rules have been reactivated for the first time following an upgrade.
  5. Once you have set up RBAC, you must reconfigure the access permissions for legacy items. They will not yet be visible to any users other than the one performing the upgrade.
    Permissions for the following items will be affected:
    • Dataflows
    • Destination Templates
    • Notifications
    • Policies
    • Schedules

    When these items are created in Protector 6.x, the user creating them is given Read/Write Access, allowing that user to see and change them. Users with the RBAC Override Ownership Permissions privilege can also see and edit them. Nobody else will be able to read or modify these items unless granted access.

    When upgrading to 6.x, no Permissions are set for legacy items. This means that ONLY users with the RBAC Override Ownership Permissions privilege can see and edit them. For other users to see the upgraded items they will need to be granted access permissions.

    Users without the RBAC Override Ownership Permissions privilege are prevented from removing all permissions; although they can still remove their own access if required. Only users with the RBAC Override Ownership Permissions privilege can remove all permissions.

  6. If you have not yet done so, refactor any large, complex or parallel data flows as described above.
  7. If you have not yet done so, check that all nodes that were members of node groups are still present and that no warnings have been logged regarding node type mismatch as described above.
  8. Re-configure the notification events that you made a note of prior to upgrading. These will have been deleted during the upgrade process.
  9. VMware policies will work as before. However the policy wizard will not show any servers selected. The required selections must be remade.