Best practice backuping freeipa in docker

[Petar Kozić]

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?

Do I need to use backup scripts or some different method?

Thank you in advance.

*—*

*Petar Kozić*

[Brian Topping]

>  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.

[Petar Kozić]

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.

[Brian Topping]

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.

[Petar Kozić]

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.