I could do incremental backups for, say, every day of the week, and at the end of the week compact my DB and do a full backup. This way I could roll back do any day during the last week.
If I could precisely roll back a DB (something like what Dirkjan said: roll-back-n-seqs, or roll-back-t-seconds), I could skip the incremental backup and simply replicate. That way I would only need to do a backup before compaction. On 25 November 2010 15:55, Robert Newson <[email protected]> wrote: > "Maybe theoretically, I could make a roll back on any db, simply by > chopping > off some bytes from the end?" > > Yup, you can do that. CouchDB will seek backward from the end of the > file for the latest db header and then carry on as normal. > > The real question is why you would want to? This scheme also prevents > you from ever compacting, as this will remove the previous revisions > of your documents. > > B. > > On Thu, Nov 25, 2010 at 1:48 PM, afters <[email protected]> wrote: > > This way I could recover from failure, but I couldn't roll back to a > > previous point in time as I could with incremental backups. > > > > Maybe theoretically, I could make a roll back on any db, simply by > chopping > > off some bytes from the end? > > > > On 25 November 2010 14:38, Robert Newson <[email protected]> > wrote: > > > >> The best way to backup is via replication, in my opinion. You can do > >> this continuously so your backup will be very close to the original. > >> > >> On Thu, Nov 25, 2010 at 12:36 PM, Robert Newson < > [email protected]> > >> wrote: > >> > "but are ALL db changes indeed append only?" > >> > > >> > Yes. the file is opened with O_APPEND, we *can't* write anywhere but > >> > the end of the file. > >> > > >> > Earlier versions of couchdb would update the header (the first 4k of > >> > the file) but that is no longer the case. It's strictly append only. > >> > Any truncation of the .couch file will yield a consistent database > >> > (obviously missing the most recent changes". > >> > > >> > B. > >> > > >> > > >> > On Thu, Nov 25, 2010 at 11:41 AM, afters <[email protected]> > wrote: > >> >> I guess I'm not sure as to what's going on with the file as it is > being > >> >> copied and changed at the same time. I assume that the file must be > >> >> append-only for this to work, but are ALL db changes indeed append > only? > >> I > >> >> remember reading that updating a tree-node also updates all its > >> ancestors > >> >> (to track latest seq) and I wonder if those changes are also append > >> only. > >> >> > >> >> On 25 November 2010 13:21, Robert Newson <[email protected]> > >> wrote: > >> >> > >> >>> just copy the file, there's no need to stop couchdb. Replication > would > >> >>> be another way, of course. > >> >>> > >> >>> On Thu, Nov 25, 2010 at 11:16 AM, afters <[email protected]> > >> wrote: > >> >>> > hi folks, > >> >>> > > >> >>> > As I'm about to implement it myself, I'm curious to know how > people > >> >>> handle > >> >>> > incremental backups for their DB's. > >> >>> > > >> >>> > The straight-forward way, as I see it, is to shutdown couch and > use a > >> >>> tool > >> >>> > like rsync or duplicity to backup db files. It should do the job > >> well, > >> >>> and > >> >>> > as an added bonus, it could also be used to backup views. > >> >>> > > >> >>> > Does anyone know if a similar backup could be done while the couch > is > >> >>> still > >> >>> > on (and the db is being updated)? > >> >>> > > >> >>> > Does anyone do incremental backups using replication? > >> >>> > > >> >>> > a. > >> >>> > > >> >>> > >> >> > >> > > >> > > >
