Harry G Coin via FreeIPA-users wrote:
What's the 'current best practice' for what you might call a 'fully deployed' freeipa install (meaning one that uses DNSSEC and all the documented capability subsections)?
From what I can tell, there are two approaches:
Approach 1: Run it in a VM, then from time to time shut it down, snapshot the 'known good' image, then bring the VM back up'. When there's a problem that's not 'trivial', just revert to the 'known good' snapshot and pay the price of re-entry of lost data.
The reasoning here is: Freeipa is much too interwoven among all the sub-packages and dependency-hell, the time required to re-enter data necessary to bring a backup current is at least known, compared to the almost impossible-to-guess time and multi-package expertise required to diagnosis much less cure problems in anything like the time available in production environments.
Yes, this can help back out of failed upgrades, for example. Note that this and any backup and restore procedure can wreak havoc on replication. If you effectively take one server back in time then you should re-init it from another server.
I'm not sure why you bring up dependencies in the context of backup and restore.
Approach 2: Use the ipa-backup, ipa-restore commands. Just keep a fresh install of the unconfigured pacakges, do ipa-restore and it will get every single detail correct across all the available documented functionality, databases, including the dnssec ones and the other 'trust' addons, etc.
The reasoning here is: It's better than approach 1 in that you don't have to take down the system even for a moment to get a 'known good' snapshot. However, you have to trust there is testing of 'everything the ipa-backup ipa-restore' process does actually does test the whole of the documented functionality.
For production reasons we'd prefer approach 2, as taking the system down and bringing it back up as in approach 1 introduces a momentary loss of capability but has the benefit of 'total confidence'. But is it really 'the best approach' in the production world?
Backups are a good thing to have, but restoration should be due to catastrophe. When doing a restore recommend deleting all other servers and re-installing. You could conceivably re-init from the restored server as well, but it really is a nuke from orbit operation.
In either situation there will be down time.
Some level of backup is essentially online with MMR in 389-ds. This can't prevent undesired loss or modification of data but it otherwise provides the uptime you seem to be looking for.
rob