samba - Dec 2014 - sysvol /etc /private replication/backup via git

Hello List,
we have a running (test) AD samba4  system running successful for several month.
We are now trying to add more DCs to the mix
and have a proper backup/desaster recovery strategy.

Basically I wan't to adapt the samba_backup script found in the sources to
backup everything via git into our repository. I understand that the best
solution would be to tar everything before commit.

In case of disaster recovery I wan't to write another script that restores
everything from our repo.
With the similar technology I wan't to synchronize sysvol.

Did anyone try this already? Do you see pitfalls why this is a bad idea?
Any comments are highly appreciated.
Ty
Johannes


-- 
Johannes Amorosa | Celluloid VFX

Hello Johannes,

Am 18.12.2014 um 12:23 schrieb johannesa:
> Basically I wan't to adapt the samba_backup script found in
> the sources to backup everything via git into our repository.
> I understand that the best solution would be to tar
> everything before commit.
You don't have to use tar. But you have to ensure, that you have a
backup, that includes the extended ACLs and attributes. And tar --xattrs
is an easy way.




> With the similar technology I wan't to synchronize sysvol.
Why not simply use an rsync based way, to keep everything in sync?
https://wiki.samba.org/index.php/SysVol_Replication
Easy to setup. Changes (e. g. GPO) are done on one host. All other are
pulling the changes.



> In case of disaster recovery I wan't to write another script
> that restores everything from our repo.
If your backup is only for sysvol: If you use rsync (see above) for
replication, a lost sysvol folder would automatically recovered if it's
one of the rsync slave hosts. You would only need a sysvol backup of the
host that is master for the others. And for that one host I would do the
restore manually. That are just some few steps to do and then I'm sure,
that it's done right and I can react, if something changed, that was
forgotten in the script.



> Did anyone try this already? Do you see pitfalls why this is a bad idea?
> Any comments are highly appreciated.
- You have to keep ext. ACLs/attributes

- Keep the time as short as possible, if files change. rsync transfers
the changed file with a temporary name and then replaces the file. This
is just a very short moment, where the file is not accessable.



Regards,
Marc

Just to mention and because I'm in doubt: The samba_backup script contains
tdbdump for private folder to create online dumps of all ldb. But the dumps are
smaller than the original. Is that ok?
I'm in doubt regarding integrity.

Am 20. Dezember 2014 10:59:59 MEZ, schrieb Marc Muehlfeld <mmuehlfeld at
samba.org>:
>Hello Johannes,
>
>Am 18.12.2014 um 12:23 schrieb johannesa:
>> Basically I wan't to adapt the samba_backup script found in
>> the sources to backup everything via git into our repository.
>> I understand that the best solution would be to tar
>> everything before commit.
>
>You don't have to use tar. But you have to ensure, that you have a
>backup, that includes the extended ACLs and attributes. And tar
>--xattrs
>is an easy way.
>
>
>
>
>
>> With the similar technology I wan't to synchronize sysvol.
>
>Why not simply use an rsync based way, to keep everything in sync?
>https://wiki.samba.org/index.php/SysVol_Replication
>Easy to setup. Changes (e. g. GPO) are done on one host. All other are
>pulling the changes.
>
>
>
>
>> In case of disaster recovery I wan't to write another script
>> that restores everything from our repo.
>
>If your backup is only for sysvol: If you use rsync (see above) for
>replication, a lost sysvol folder would automatically recovered if it's
>one of the rsync slave hosts. You would only need a sysvol backup of
>the
>host that is master for the others. And for that one host I would do
>the
>restore manually. That are just some few steps to do and then I'm sure,
>that it's done right and I can react, if something changed, that was
>forgotten in the script.
>
>
>
>
>> Did anyone try this already? Do you see pitfalls why this is a bad
>idea?
>> Any comments are highly appreciated.
>
>- You have to keep ext. ACLs/attributes
>
>- Keep the time as short as possible, if files change. rsync transfers
>the changed file with a temporary name and then replaces the file. This
>is just a very short moment, where the file is not accessable.
>
>
>
>Regards,
>Marc
>-- 
>To unsubscribe from this list go to the following URL and read the
>instructions:  https://lists.samba.org/mailman/options/samba