#50606 Restore backup fails if the backed up backend was removed
Opened 3 months ago by spichugi. Modified 2 months ago

Issue Description

Restore backup works on an existent backend but doesn't work if there is no backend (it was removed after a back up).

Package Version and Platform

389-ds-base-1.4.2.0-20190916git99f113122.fc30.x86_64

Steps to reproduce

  1. Create backend with suffix and entries
  2. Create a backup
  3. Remove the backend
  4. Try to restore the backend using restore task

Actual results

The operation fails with Unwilling to perform error.
Error log has the next message:

[16/Sep/2019:16:40:42.491330044 +0000] - ERR - task_restore_add - No archive2db function defined.

Expected results

It should succeed


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

Metadata Update from @lkrispen:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

3 months ago

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.

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.2

2 months ago

Login to comment on this ticket.

Metadata