-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cc'ing group list back in for other opinions.
On 05/22/2012 03:38 PM, Rich Megginson wrote: > On 05/22/2012 08:36 AM, Dmitri Pal wrote: >> On 05/22/2012 10:10 AM, Rich Megginson wrote: >>> On 05/22/2012 04:38 AM, Dmitri Pal wrote: >>>> On 05/22/2012 04:28 AM, Dale Macartney wrote: >>>>> Dmitri, Rob >>>>> >>>>> I thought I might reply to you both directly, just in case others on >>>>> the list vent frustrations on the ongoing discussion of this topic. >>>>> >>>>> I've been reading through the archives of the list for hot backup >>>>> solutions, and this email thread really stood out. I am seeing a >>>>> general consensus of backing up everything, and in some cases, even >>>>> backing up a virtualized guest disk image to maintain a backup. I >>>>> personally feel this is the wrong message people should be getting >>>>> into their heads about a DR solution for restoring IPA. >>>>> >>>>> I was wondering, and feel free to correct me here if you see fit, if >>>>> it would be beneficial to have a similar method of backing up IPA (and >>>>> replicas), in a similar fashion to how Microsoft recommend their >>>>> Domain Controllers to be backed up. A "system state backup" of sorts. >>>>> Where a backup is performed on all Domain Controllers (or in our case, >>>>> IPA servers). Basically, resulting in an individual restore point for >>>>> each replica. From here, you have an entire backup, which will only >>>>> ever bee used for that ONE server it was intended for. Essentially a >>>>> complete dump and load approach. >>>>> >>>>> It is best practice in a Windows environment to perform these backups >>>>> several times a week in small non-changing environments. So my >>>>> thinking is, if we have a "daily backup" solution which could be used >>>>> to run on each replica or master, then this should suffice in an >>>>> adequate procedure to give to customers. >>>>> >>>>> In short, I'm more than happy to put my hand up on this one to help >>>>> free up your time. I can easily take this on with a few of the lads >>>>> here in the UK and get some customer feed back from mates within my >>>>> former employment who are quite well versed in the realms of IPA. >>>>> >>>>> Would this be of any help to you? Do you see this as the right >>>>> direction to take on this matter? I'd love to hear your thoughts >>>>> >>>>> Rhys, Gav, cc'ing you in on this one. I'd like to throw this onto our >>>>> running list of IPA integration projects. >>>>> >>>>> Regards >>>>> >>>>> Dale >>>> First of all thank you for the offer! >>>> >>>> It seems that there are two main use cases: >>>> 1) Catastrophic failure >>>> 2) Data deletion >>>> >>>> In the case of the catastrophic failure you want to have all >>>> data+configuration+keys backed up to be able to effectively start over >>>> and re-install/recover from the backup. could we not have the ability of restoring only specific data? Like most backup solutions? for example having a utility where you can run "ipa backup all" could cover the data+config+keys, however depending on a catastrophic failure or data deletion, maybe have something along the lines of "ipa restore data" if we simply wanted to restore the data element of the backup. Thoughts? IMO, i think we should look for a KISS method which is specific to the application stack at hand. >>>> In this case IMO having a VM approach like the one JR uses is a viable >>>> solution. Rob, Simo, Rich do you agree? >>> We would need to test this to make sure VM snapshots don't cause >>> problems with replication and/or kerberos since those are sensitive to >>> time. All of the testing we have ever done for RHDS/389 for >>> backup/restore is based on simple database binary and ldif backups. >>> We've never had to take into account restoring to a filesystem time in >>> the past or a VM state that is in the past. >> Why in the past? >> If you take snapshots regularly say every other day when you restart a >> VM it should act as if the connection to it was lost for couple days. > > Ok. Maybe it will work just fine. All I'm saying is that we better test this well with a number of replication scenarios. Should we really be considering snapshots as an "IPA" method of recovery? That puts a prerequisite on the customer using either SAN snapshotting or virtualization technologies. If I use RHEV 2.2 as an example here, RHEV was not adopted by many customers because there was a prerequisite of Windows. If we have a reliance on other technologies for such key recovery principles this will undoubtedly (possibly more in the short than long term) have a knock on effect of adoption. Yes it might work, but should we be sending this message across? In the short term, if it works then great, however I think this should give us insight into a more robust method in the future. > >> I do not see how the Kerberos and time are related here. >> >>>> In the case of data deletion we one needs to keep LDAP data around and >>>> not necessarily all the configuration and keys. And not even all the >>>> data needs to be backed up. >>>> >>>> So there should probably be two different procedures. >>>> >>>> I also think that creating a VM snapshot and recovering from such >>>> snapshot can be automated. We should probably provide some kind of >>>> script or command to do so. >>>> We stayed a bit shy from either procedure because the set of the config >>>> files IPA touches changes all the time and until we get it stable it >>>> would be hard to commit to a flawless backup. We feel we will miss >>>> something and will get bugs that we will have to address. Yeah in the >>>> current state there is a bit of hand-waving... May be it is time to >>>> identify the set of of all things we touch on the system and try to have >>>> a more solid set of procedures and recommendations and bite the bullet >>>> if we miss something. >>>> >>>> Now back to your offer, first of all which of the two use cases you >>>> think you would be able to contribute to? >>>> Do you think it makes sense to script something for either of the cases? >>>> What? Would you be able to help? >>>> >>>> JR offered help too. He is waiting for the blessing to describe a VM >>>> based approach. So first we should decide if it is the right way to go. >>>> For the first case IMO it is but I want other opinions. >>>> >>>> And one more thing. May be we should continue this thread on the list so >>>> please reply there. >>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPu7mGAAoJEAJsWS61tB+q5MkP+wYr0nK5u0BzWV0Ar7dE7EXj mC+oxwv3Q+H7fluDXgd7r+HeLhAQU0i+FmVLraQHWvoNN99l11s5RtChu6dPaICW ThgPP/k85uNUyiBJysePgB/xv+VTaRJ9SZVMPxecLBE72U7RZHAWDRAvYS9yU1Dv 4qVB9KOQdvTrxjOITH7XEDx9LbZmNQ2ViWOxQTbHY23v6t1VRXmgIRcWtKcfBgJd sq69fOA4pXV6YfHnk/gYoT5TIclZnv/qUzKPEGI/XvPuohzLjsdnfsoEQZpXzSxz L+U7sVYDGSq5EoOKEmFT4MdHEG7niGUbYLzIx8RD+uzXbPtI11BECe/esGF7pYkJ U4yxrnxPMxSmja9hccPephdNodmbBht4t4UKuFBVOfOC1N/yhOgys6MH4bbQmOMR dN9/fLJAVVdIjMiytsCNvFXH4rM44nJ9wzW5xziUx+472qjFjUn7Jwudp3n1+fB5 w5JrY0R1315tLS4Bxhqhzx9wQFALytKgilxJhx2DW1RghQTk6YcFg7fF1ELXfJsH YcnOEbzcv20vwEcFTb8ilejvJorZACGTbKg9U3oMoz5WQEoMg448m6SL2Rp7J8+0 dFUyA78HzklbqPBgAGgWdXQ9ZKR+oUVigYEynZ4pUxKH7KWDitOtZHKUlxx1BFKq n/BzLu9/FUEsMvOcsp23 =ENst -----END PGP SIGNATURE-----
0xB5B41FAA.asc
Description: application/pgp-keys
0xB5B41FAA.asc.sig
Description: PGP signature
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
