Is it possible to do live backups of a running DB with rsync??? I was just talking to livevault.com & they (only on win boxes) say they can grab changes from a client's live DB & sync them remotely. It sounded like BS to me, but I'm neither a DB guy or sync'ing expert. Steve Mallett
On Tue, 2003-01-14 15:44:26 -0400, Steve Mallett <spaceman@nbnet.nb.ca> wrote in message <96CCDE1A-27F8-11D7-AAAB-000393D8DD4A@nbnet.nb.ca>:> Is it possible to do live backups of a running DB with rsync??? > > I was just talking to livevault.com & they (only on win boxes) say they > can grab changes from a client's live DB & sync them remotely. > > It sounded like BS to me, but I'm neither a DB guy or sync'ing expert.I think that's BS (or to name it for non-natice english speakers: bull shit:-). Even if you had somethink like LVM to take a snapshot, the database will be in some inconsistent state. There are only two (well, three) sane ways of backing up a DB: - Shutdown, then take a backup (or take a LVM snapshot and restart immediately afterwards). - Use some backup functionality the database server itself offers - Use a combination of both - some DB servers are IIRC capable of not touching some primary DB files/storage areas for some time but collecting any changes outside MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur fuer einen Freien Staat voll Freier B?rger" | im Internet! Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20030114/aa9f3608/attachment.bin
On Tue, 14 Jan 2003, Steve Mallett wrote:> Is it possible to do live backups of a running DB with rsync??? > > I was just talking to livevault.com & they (only on win boxes) say they > can grab changes from a client's live DB & sync them remotely. > > It sounded like BS to me, but I'm neither a DB guy or sync'ing expert.I've done with unix DB, DB4, and MySQL backends [not of choice, but sometimes, there's no other way, as when a hard drive is dying, and you _know_ you will never be able to power it on again ...] -- it works this way -- 1. Rsync the directory tree holding the database 2. Re-run the command 3. Keep re-running it, and eventually, you'll get an essentially immediate return with no content being moved. ... at this point stop. You hit a time when the database was largely quiescent, and so was unchanged -- -- there will be some open locks and and open transactons will be lost -- but no worse than an unplanned reboot due to a power loss. In a production environment, it seems to me that better ways usually exist. -- Russ Herrold
On Tue, Jan 14, 2003 at 03:44:26PM -0400, Steve Mallett wrote:> Is it possible to do live backups of a running DB with rsync??? > > I was just talking to livevault.com & they (only on win boxes) say they > can grab changes from a client's live DB & sync them remotely. > > It sounded like BS to me, but I'm neither a DB guy or sync'ing expert.On it's face It sounds like worse the BS. Depending on which BS you can either grow roses or enjoy "the way we were". Generally MS OSs you can't even rsync an open file. As such, to sync tablespaces you have to shut down the database. It could be they are using something like debase where you use a set of libraries to access the data files directly and there is no back end running. The files are only accessed during transactions so you could squeeze an rsync in between accesses. I believe the the MS Access DB[sic] works this way. A service oriented database (Oracle, SQLserver, pgsql, mysql, etc) keeps the files open all the time and even if you can read them the database will be inconsistent. What you may be able to do is to rsync the commit log. This is a common practice in *IX systems. On windows it may be problematic doing this because of locking on open files. This method does work and by replaying the logs whenever they change can be used to keep a running copy of the database almost up-to-date to allow for a limited (the most recent transactions may be lost) fail-over capability. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt