No, it should not work.

A backup can only be retored to a server which has the exact same configuration, backends, indexes,.. as the backup. It backs up only data not a configuration.

So if you remove backend after backup the backup data no longer match and restor has to fail.

Another comment: the scenario 1..4 looks like backup/restore of a single backend. This feature should no longer exist, in the server and in the utilities

Okay, then I can rephrase the issue.
We can fix the error log here because the only message No archive2db function defined. is useless and misleading in my opinion.

Another comment: the scenario 1..4 looks like backup/restore of a single backend. This feature should no longer exist, in the server and in the utilities

In the scenario, we don't restore a single backend exclusively (there is no option anymore). So for the clarification, I'll add another backend.

Okay, then I can rephrase the issue.
We can fix the error log here because the only message No archive2db function defined. is useless and misleading in my opinion.

yes, absolutely

In the scenario, we don't restore a single backend exclusively (there is no option anymore).

good

So for the clarification, I'll add another backend.

Just to be clear, as soon as you modify the backends or their configuration after the backup, the restore should fail.

I did a few experiments and got some surprises:

• a backup creates two files in the backup directory dse_instance.ldif and dse_index.ldif, whci contain the configuration at the stae of the backup. But at restore they are checked only after the restore has been done and if a difference is noted, only a warning is logged

• if you edit dse_instance ldif and add an instance, at restore an instance is created, without any useful, I would expect it top be rejected.

• if you do a backup of of an instance with two backends and then remove one in the dse.ldif and try to restore it fails (as I would expect) and gives these error messages.

  [17/Sep/2019:10:52:59.873999563 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000
  [17/Sep/2019:10:52:59.902194104 +0200] - ERR - dblayer_restore - Target server has no abcd configured
  [17/Sep/2019:10:52:59.908473254 +0200] - ERR - ldbm_back_archive2ldbm - Failed to read backup file set. Either the directory specified doesn't exist, or it exists but doesn't contain a valid backup set, or file permissions prevent the server reading the backup set. error=53 (Invalid request descriptor)

This seems to be like the sceario addressed in the ticket and the messages seem meaningful

This issue was originally found in the UI because you can successfully take a backup of an empty backend, but you can not restore that backup. So either the backup should fail, or we should allow the restore to work.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3662

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.