>>> On 25 May 2010, at 11:56, Vidar Ramdal wrote: >>> >>>> According to [1]: "Database persistence managers: many databases >>>> support online backup, so if you use that you should be safe.". >>>> >>>> Does this mean that a hot backup is "guaranteed" to be consistent when: >>>> - The datastore is backed up >>>> - The database is backed up using the database vendor's tools >>>> >>>> [1] http://wiki.apache.org/jackrabbit/BackupAndMigration >> >> On Tue, May 25, 2010 at 1:12 PM, Ian Boston <[email protected]> wrote: >>> From a RDBMS point of view, if the vendors tools claim consistency, then >>> that what you will get, only for the RDBMS. >>> >>> You will need to do >>> DB backup >>> Datastore (assuming file persistence) backup , since its append only and >>> will be consistent with the DB. >>> in that order.
> On 25 May 2010, at 12:22, Vidar Ramdal wrote: >> Thanks for your quick reply. >> >> OK, so backup the DB first, then the datastore directory. Fine. >> >> Just to be clear: You're saying that a hot RDBMS backup should be >> consistent (thus restorable), even when the backup is run while >> Jackrabbit is writing to the DB? >> >> Do you yourself use this procedure? On Tue, May 25, 2010 at 1:35 PM, Ian Boston <[email protected]> wrote: > Yes, on MySQL we use mysqldump against a mysql slave connected to a master DB. > Mysql unfortunately does some locking of tables that makes things runs slow, > so thats why we do it on a slave. (thats how it guarantees consistency) Thank you, that's very helpful. > For Oracle, there is a well documented procedure for hot archive logging and > hot backups. For others there are equivalents. > > The only thing you might consider is although you will get a consistent DB > and the DB will have all the state it expects in the Datastore (although the > Datastore may have more state than the DB expects), if your users are half > way though a non transacted operation (ie web form flow) you might get their > state half way through. Not much you can do about that, except at the > application level. Yup. Not much of a problem in our application. I guess we'll deal with that if/when it happens :) -- Vidar S. Ramdal <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 22 00 84 76 Quando omni flunkus moritatus!
