I think it will be difficult to just use such a complete backup on another server. The dse.ldif contains host specific configuration.
For example you cannot just move the repl agreements from one server to another without adjusting them

I agree. Others host specifics info are (not exhaustive): paths (db/config), processor architecture, nss keys/certs.
I think it would be doable (and great) to use a given host backup to initialize an other instance but currently with a long restriction list.

@lkrispen The use case isn't migration, yes there is host specific information. It's "Ohh my server blew up, I want to restore DS on the same host".

A better example is: " I'm about to make a change, so I backup, and the change fails. Then I can restore to "before" the change on the same host". IE dse.ldif changes and others.

@lkrispen The use case isn't migration, yes there is host specific information. It's "Ohh my server blew up, I want to restore DS on the same host".
A better example is: " I'm about to make a change, so I backup, and the change fails. Then I can restore to "before" the change on the same host". IE dse.ldif changes and others.

That makes sense, but in the issue description it says:

 The end goal should be that a backup from server A can be restored on Server B and "just work".

Perhaps I should clarify that as "from a server with state, we restore on a clean server as a replace ment of that machine."

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/2562

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.