rsync read block size

[Matthias Schniedermeyer]

On 22.05.2009 20:30, Ming Zhang wrote:
> it become a BDD question now.. ;)
> 
> On Fri, May 22, 2009 at 5:37 PM, Matthias Schniedermeyer <ms at citd.de> wrote:
> > On 22.05.2009 16:25, Ming Zhang wrote:
> >> Hi All
> >>
> >> We want to use rsync to backup a live Berkley db to a remote site. BDB
> >> has a requirement that read has to be in the unit of db page size. So
> >> wonder how could we make sure that rsync can follow that? If we need
> >> to change the code, where we should begin to look at? Thanks!
> >
> > The read block size is irrelevant, the problem you have is consistency.
> >
> > If you want a working copy of a database (and this goes for any
> > database) you have to quiescent the database first. Otherwise the
> > file(s) in the filesystem may not be in a consistent state.
> 
> if i stop the DB operation, then yes, block size does not matter any more.

Except doing the database copy on a higher level there is not much else 
you can do.

> but actually base on BDB document, you CAN copy the files, just need
> to be careful on the order of files that get copied. i will use
> db_hotbackup to figure out the file order and feed that to rsync as
> files-from. now the block size question become relevant.

No. The block size is NEVER relevant for a copy via rsync, bits are bits 
regardless of you copying them bit by bit or in larger groups.

The man-page of db_hotbackup meantions (indirectly) that the backup is 
without cooperation from the application and the database content may be 
inconsistent. Not from the technical standpoint of BDB, but from the 
high-level application standpoint. The application has to use 
transactions correctly so that the database-content is consistent at any 
point in time.

In short: If your application does correcy transactions, hotbackup 
appears to be a useable variant of the "snapshot"-db-backup type.

> > Also you must either quiescent the database the WHOLE TIME you back it
> > up, or you must use some form of snapshoting for the filesystem and then
> > backup the snapshot. (quiescent -> Snapshot -> unquiescent)
> > (Or use some other database depend backup procedure)
> >
> > How you quiescent a database is about as database dependend as it can
> > get and personally i don't know how the procedure is for a BDB.
> > But i guess(!) you need cooperation from the program(s) working with the
> > db.
> >
> >
> >
> > Googling: backup berkeley db
> > Appear to give answers, but i only took a quick glance.
> >
> >
> >
> > Bis denn
> >
> > --
> > Real Programmers consider "what you see is what you get" to be just as
> > bad a concept in Text Editors as it is in women. No, the Real Programmer
> > wants a "you asked for it, you got it" text editor -- complicated,
> > cryptic, powerful, unforgiving, dangerous.
> >
> >

-- 




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.