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

Types of Conflicts

The restoration process can encounter several types of conflicts, which are the following:

  • 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 limits for this particular user (e.g., disk space limit).
    • Unique resource usage conflict: An object being restored requires a unique resource which is already used by another object in the system or does not exist (e.g., domain).
  • Configuration conflicts. It might happen that configuration being restored is not enabled on the destination server. Two types of cases can happen here:
    • Configuration options are not enabled for the domain.
    • Required configuration options are not available (e.g., site applications are not available for the customer, database server is not configured on the host, IP address is not allocated to the reseller, etc.)

Conflict Resolutions

The following types of conflicts resolutions are possible:

  • Overwrite. 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/setting from backup does not exist in Plesk, it is created.
    • If an object/setting from backup exists in Plesk, it replaces the existing.
    • If an object/setting exists in Plesk but is missed in a backup, the existing remains.
  • Proceed with current. Means that objects which currently present in the system won’t be affected by the restoration process. The restoration process will move to the objects belonging to that one, not touching the object itself.
  • Do not restore. Means that the objects which currently present in the system or were deleted after the backup won’t be restored together with the lower level objects belonging to it.
  • Automatic. Means that configuration option that should be enabled for domain is enabled automatically.
  • Overuse. Means that objects are restored with the resources overuse. Can be applied only to objects that belong to a reseller who works in the oversell mode.
  • Rename. Means that unique resources for the restored domain are reassigned with the specified, existing in the system (mapping).

Conflict Resolution Policies and Rules

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

  • Rule defines the way of how a specific single conflict should be resolved.
  • Policy defines the way of how 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 resolve not all the conflicts occurred. In such cases, those who perform restore 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.

Simplified presentation of the conflicts resolving during restore is as follows:

  1. Administrator runs pleskrestore with specific parameters.

  2. pleskrestore detects the conflicts occurred and resolves them with the default policies.

  3. pleskrestore checks if any conflicts remain unresolved.

    In case all conflicts are resolved, the restoration continues.

  4. pleskrestore stops the restoration and, if run in debug or verbose mode, returns detailed description (in XML format) of each remaining conflict.

  5. Basing on the returned description of the conflicts, administrator creates a file that defines a resolution for each conflict (with rules) and/or in bulk (with custom policies).

  6. Administrator runs the pleskrestore utility with the --conflicts-resolution option and the file created at the previous step as its argument.

  7. pleskrestore detects the conflicts occurred and resolves them with 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 rest of the conflicts.

  9. pleskrestore checks if any conflicts remain unresolved.

    • In case all conflicts are resolved, the restoration continues.

    • In case any conflicts remain unresolved, pleskrestore stops the restoration and, if run in debug or verbose mode, returns detailed description (in XML format) of each remaining conflict.

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