Conflict Resolution Rules and Policies

Conflict is a situation when Plesk object settings in a backup and Plesk object settings on a destination server are such that restoring a backup object leads to an error or unpredictable Plesk behavior.

Types of Conflicts

The restoration process can encounter several types of conflicts, as follows:

• Timing conflicts. An object being restored might exist in the system and its last modification date might be more recent than the date of backup. Or an object could be deleted from the system later than the backup was created.
• Resource usage conflicts. There are two groups of resource usage conflicts:
  • Common resource usage conflict: The total amount of measurable resources after restoration might appear to be over the limit for this particular user (for example, disk space limit).
  • Unique resource usage conflict: An object being restored requires a unique resource which is already being used by another object in the system or does not exist (for example, domain).
• Configuration conflicts. It might happen that the configuration being restored is not enabled on the destination server. Two situations can arise here:
  • Configuration options are not enabled for the domain.
  • Required configuration options are not available (for example, web applications are not available for the customer, database server is not configured on the host, no IP address is allocated to the reseller, and so on).

Conflict Resolutions

The following conflict resolutions options are possible:

• Overwrite. This means that all objects will be restored from the backup files regardless of their current presence in the system. Overwrite works as follows:
  • If an object or a setting from backup does not exist in Plesk, it is created.
  • If an object or a setting from backup exists in Plesk, it replaces the existing object or a setting.
  • If an object or a setting exists in Plesk but is missing in a backup, the existing object or a setting remains.
• Proceed with current. This means that objects that are currently present in the system will not be affected by the restoration process. The restoration process will proceed to the objects belonging to the object that already exists in Plesk, without making modifications to that object.
• Do not restore. This means that the objects that are currently present in the system or were deleted after the backup will not be restored with the lower level objects.
• Automatic. This means that configuration option that should be enabled for domain is enabled automatically.
• Overuse. This means that objects are restored even when the resources are overused. Can be applied only to objects that belong to a reseller who is working in the oversell mode.
• Rename. This means that unique resources for the restored domain are reassigned with the specified name, existing in the system (mapping).

Conflict Resolution Policies and Rules

Depending on the scope of a conflict resolution, we distinguish between conflict resolution rules and policies:

• Rule defines the way a specific single conflict should be resolved.
• Policy defines the way all conflicts of a particular type should be resolved.

Conflicts Resolving Mechanism: Default Policies, Custom Policies, and Rules

The restoration utility brings a set of default, hard-coded conflict resolution policies, which are as follows:

• For timing conflicts - Overwrite
• For common resource usage conflicts - Overuse
• For unique resource usage conflicts - Do not restore
• For configuration conflicts - Automatic

The default policies are always applied during restoration and cannot be changed or overridden.

Applying default policies may not resolve all the conflicts that occur. In such cases, the person performing the restoration should additionally define custom rules and/or policies that resolve the remaining conflicts. Custom rules and policies are defined in an XML format as described in the section Resolutions Description Format.

A simplified presentation of conflict resolving during restoration is as follows:

1. Administrator runs pleskrestore with specific parameters.
2. pleskrestore detects the conflicts that have occurred and resolves them using the default policies.
3. pleskrestore checks if any conflicts remain unresolved.

   If all conflicts are resolved, the restoration continues.

4. pleskrestore stops the restoration and, if run in debug or verbose mode, returns a detailed description (in XML format) of each remaining conflict.
5. Based on the returned description of the conflicts, the administrator creates a file that defines a resolution for each conflict (with rules) and/or in bulk (with custom policies).
6. The administrator runs the pleskrestore utility with the --conflicts-resolution option and the file created in the previous step as its argument.
7. pleskrestore detects the conflicts that have occurred and resolves them using the default policies.
8. pleskrestore processes the remaining conflicts:
   1. pleskrestore applies resolution rules from the file.
   2. pleskrestore applies resolution policies from the file to the remaining conflicts.
9. pleskrestore checks whether any conflicts remain unresolved.
   • If all conflicts are resolved, the restoration continues.
   • If any conflicts remain unresolved, pleskrestore stops the restoration and, if run in debug or verbose mode, returns a detailed description (in XML format) of each remaining conflict.

     To have such a dump restored, the administrator should add resolution rules for each remaining conflict to the conflict resolution file and repeat the restoration task.