mtree replication import fails: nsrmmdbd SQLITE severe constraint failed

Summary: Mtree replication fails because it is trying to import a saveset that already exists in the media database of the target server causing the error: nsrmmdbd SQLITE severe constraint failed ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Server is configured with DD device replication.
Version is 19.9.0.4 or below.
Export is working fine.
Import is failing.

Cause

There are 2 possible scenarios where this issue could appear.
Due to a bug in Version is 19.9.0.4 or below, the "NSR DD device replication" resource might be deleted from the server after a restart of services. This can lead to two situations:
  1. On the source server, the "NSR DD device replication" resource is deleted. The reference of the "last replication time" is lost. The next export operation will not export those savesets after the last export, but rather simply export all savesets that are in the volume. At the import time, many of those ssids would have already being imported previously and hence the error message: SQLITE severe constraint failed, since we cannot insert an ssid twice.
  2. On the target server, the "NSR DD device replication" resource is deleted. The reference of the "last replication time" is lost. the next import operation will not import new savesets after the last import time. Instead, it will try to import all savesets. But many of those savesets were already imported, and hence will fail.

Resolution

Since the failure is derived from the "NSR DD device replication" resource being deleted, the only fix is upgrading to 19.9.0.5 or 19.10 to avoid the issue to happen.

Possible workaround:
Workaround A:
1. find out which was the "last replication" time from "NSR DD device replication" resources found in nsr/nsrdb/dbg folder
2. Delete the existing "NSR DD device replication", and create a new one with the same parameters but using the last replication time from above.

Workaround B:
If the content of the /nsr/replication folder in the target server hasn't been modified since the replication started, you can delete the entire replication volume, and run the import again (only if the last replication time of NSR DD device replication is 0).
Keep in mind that savesets cannot be deleted by the target NetWorker server, since they are on a read-only mtree; therefore, deleting the volume will not delete the savesets. On top of that, since we have the /nsr/replication folder intact, we have the information of all the savesets that have been imported since the replication job started.

Workaround C:
If you need to retrieve a specific SSID on the target server for restoration purposes, you can run scanner for the specified SSID.
since this SSID was imported with "scanner", and not through an import operation, any subsequent import operation trying to import this SSID will fail. You can just delete the saveset manually later on with nsrmm -d -S ssid, once you are done recovering it. Again, this will not delete the ssid from the Data Domain, only the reference in the media database.

Additional Information

If you need further assistance or understanding of the issue, contact support.

Affected Products

NetWorker
Article Properties
Article Number: 000222759
Article Type: Solution
Last Modified: 07 Mar 2024
Version:  1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.