couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From afters <afters.m...@gmail.com>
Subject Re: Incremental backups
Date Thu, 25 Nov 2010 14:17:21 GMT
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 <robert.newson@gmail.com> 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 <afters.mail@gmail.com> 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 <robert.newson@gmail.com>
> 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 <
> robert.newson@gmail.com>
> >> 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 <afters.mail@gmail.com>
> 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 <robert.newson@gmail.com>
> >> 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 <afters.mail@gmail.com>
> >> 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.
> >> >>> >
> >> >>>
> >> >>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message