Brian, thank you very much on answer. Can you tell me how can I check does it 389 DB consistent, and can I use freeipa backup-scripts for DB backup in docker or that is unnecessarily ? *—* *Petar Kozić* On April 16, 2019 at 7:17:56 PM, Brian Topping (brian.topping(a)gmail.com) wrote: On Apr 16, 2019, at 5:58 AM, Petar Kozić via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org&gt; wrote: Hi folks. I’m using freeipa in docker on one VM machine and for now, I satisfied how that works, but I worried about backup. Can someone tell me what is best practice for backup ipa which works in docker? One upside of Docker is a very clear picture of what will be saved across reboots. If the container reboots cleanly, the saved data must (by definition) be on a persistent volume somewhere. (I’m sure as soon as I say that, someone will have an exception to such a rule of thumb, but it works for me…) When backing up databases, the key is to generate some kind of checkpoint. Regardless of the state your backup software catches the data when it does it’s pass, the checkpoint is a state that the database is internally consistent. For the most part, files outside the 389 database are configuration oriented and will not be changing with a running system. Other organizations use things like Git to store configurations to even avoid that problem. tl;dr: Checkpoint the database before you back up, and you should be fine.

Thank you ! *—* *Petar Kozić* On April 17, 2019 at 10:07:18 AM, Brian Topping (brian.topping(a)gmail.com) wrote: Hi Petar, I’m sorry I can’t be of more help. Backups are something I’m presently working on, but starting with the persistent volumes underlying all containers rather than the specifics of a container. Once I get that working, I’m going to look at each container to figure out snapshot specifics like this. In general, I’m planning to snapshot inside the container as a local cron job, then back up the persistent volume without too much regard for its state when the backup happens. On restore, the data may be considered corrupt until it is reset to the last snapshot, but this decouples the in-container semantics from the persistent volume processes. It’s very database-specific what this means in real life, having a lot of snapshots in a database can sometimes mean that database gets huge. This may or may not be a problem for different organizations because if the snapshots are copy-on-write and the copies are separate files, an incremental backup program can easily see that the base files did not change. I was not aware there were scripts in existence, I’ll definitely want to look at them before too long. Sent from my iPhone On Apr 17, 2019, at 00:54, Petar Kozić <petar.kozic(a)mint.rs&gt; wrote: Brian, thank you very much on answer. Can you tell me how can I check does it 389 DB consistent, and can I use freeipa backup-scripts for DB backup in docker or that is unnecessarily ? *—* *Petar Kozić* On April 16, 2019 at 7:17:56 PM, Brian Topping (brian.topping(a)gmail.com) wrote: On Apr 16, 2019, at 5:58 AM, Petar Kozić via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org&gt; wrote: Hi folks. I’m using freeipa in docker on one VM machine and for now, I satisfied how that works, but I worried about backup. Can someone tell me what is best practice for backup ipa which works in docker? One upside of Docker is a very clear picture of what will be saved across reboots. If the container reboots cleanly, the saved data must (by definition) be on a persistent volume somewhere. (I’m sure as soon as I say that, someone will have an exception to such a rule of thumb, but it works for me…) When backing up databases, the key is to generate some kind of checkpoint. Regardless of the state your backup software catches the data when it does it’s pass, the checkpoint is a state that the database is internally consistent. For the most part, files outside the 389 database are configuration oriented and will not be changing with a running system. Other organizations use things like Git to store configurations to even avoid that problem. tl;dr: Checkpoint the database before you back up, and you should be fine.