The plugin has noticed that the folder at a target belongs to another installation of this website. It writes nothing more there until you answer: did the website move, or is this installation a copy?
What the fingerprint is
At every target, next to the backups, there is a small catalog. It names the website and carries the fingerprint of the installation that backs up there. The fingerprint is derived from two details: the address of the website and the path of the installation on the server.
Before the plugin writes to a target, it compares the fingerprint in the catalog with its own. If the two differ, this applies:
- Nothing is written and nothing is deleted at this target.
- Backups skip this target and end with warnings. A backup without another target fails.
- The plugin remembers the conflict and asks you on the Targets page.
The fingerprint changes when the website gets a different domain, switches from http to https or moves to a different folder on the server. It is also different when someone has copied the website: the copy has the same folder code as the original, but a different address or a different path.
How you recognise the conflict
In the list on the Targets page, the target carries a label:
- conflict appears after the name of the target. The dot at the start of the row stays as it would be without the conflict.
The status tile of the page is yellow and reports Fingerprint conflict at “…”:
- The tile names the target and, in brackets, the address of the website from the catalog at the target.
- This website moved
- This is a copy
Which answer is right
Read the address in the status tile 1 and compare it with the address of this website.
| Your situation | Answer |
|---|---|
| It is the same website, with a new address or in a new path. The installation with the old address no longer exists. | This website moved |
| This installation is a copy, for example for testing. The original keeps running and backs up to the same target. | This is a copy |
Do not answer “moved” if the original keeps running
With this answer, the folder at the target belongs to this installation. The plugin writes backups there again and deletes old ones according to Max. backups. The original would then find a foreign fingerprint and write nothing more there.
Answer 1: The website moved
Click This website moved. There is no confirmation dialog. The plugin rewrites the catalog at the target with the fingerprint of this installation and reports this below the status tile:
- Catalog at “…” written with the fingerprint of this installation; the target is used again.
The backups at the target and the list of backups stay as they are. The answer applies to this one target. If the conflict exists at several targets, the tile names all of them; answer them one after the other.
Answer 2: This is a copy
Click This is a copy. The confirmation dialog names the number of backups in the list that belong to the original.
- Cancel
- Use a new folder code
With Use a new folder code this happens:
- This installation gets a new folder code and with it its own folders at every target.
- The log folder and the work folder move along.
- The backups in the list belong to the original and disappear from the list. Nothing is deleted at the targets.
- All recorded conflicts are resolved. The answer applies to the whole installation, not only to one target.
The plugin reports: This installation now uses its own folder code; … entries of the original were removed from the list. The next backup writes into the new folder.
The targets and backup plans of the copy stay set up. The backups of the original stay in its folder at the target and continue to belong to the original.
If something does not work
| Message | What you can do |
|---|---|
| The catalog at the target could not be written. | Test the connection in the More … menu of the target and answer once more. Show log in the message leads to the details. |
| A job is running. Try again when it has finished. | Wait until the running job has finished, then answer. |
| The folder code could not be changed. | Nothing has changed at the targets and in the list. Open the log via Show log in the message. |
Good to know
- If a later backup finds the matching fingerprint at the target again, the conflict resolves itself.
- The path on the server is part of the fingerprint on purpose. So the same installation looks like a copy when it runs via a different path, for example via a symbolic link. Always let the plugin run via the path the web server uses; this also applies to WP-CLI.
- Whoever takes over the folder of an earlier installation after a total loss thereby also confirms “moved”: Find backups again after a total loss.
See also
- The “Targets” page
- Restore a backup on another website
- When a backup fails or ends with warnings
- Define how many backups are kept
- Manage targets with WP-CLI
On the command line
WP-CLI not set up yet? How to install WP-CLI.
Both answers also work with WP-CLI. The list of targets shows a recorded conflict next to the target, with the address from the foreign catalog. The answer “copy” requires the parameter --yes; without it, the command only names what would happen.
# Show targets; a conflict is listed next to the target wp cloneworx-backup target list # Answer “moved”: rewrite the catalog at the target wp cloneworx-backup target moved local-1 # Answer “copy”: new folder code for this installation wp cloneworx-backup target copy local-1 --yes