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.
- 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: