From: Reinoud Zandijk <reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org>
To: NILFS Users mailing list <users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
Cc: nilfs-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org
Subject: Re: Dump tools for checkpoints
Date: Thu, 12 Mar 2009 16:26:18 +0100 [thread overview]
Message-ID: <20090312152618.GA25317@aardappel.13thmonkey.org> (raw)
In-Reply-To: <20090308.143916.113539820.ryusuke-sG5X7nlA6pw@public.gmane.org>
Dear Ryusuke, dear Pierre,
On Sun, Mar 08, 2009 at 02:39:16PM +0900, Ryusuke Konishi wrote:
> Actually I want to realize this feature in some form, and had
> considered details several times. What I want to realize is
> checkpoint based replication including incremental dumping and
> restoration of file system states.
depends on the granlarity of the backup; do you want backup time backups or
checkpoint/snapshot based?
The first could be implemented (though not watertight) by comparing the DAT
files between checkpoint P and Q at backup time. If while parsing the filetree
at Q a change is noticed in the DAT allocation of the vblock the file is
changed.
The 2nd is easier and more logical; a snapshot is marked as the last backup
time. Then when the backup is updated, the checkpoints are walked and -just
like the cleaner- the diff is cleaned up between this snapshot and the next
backup snapshot. After the backup the old backup snapshot is either deleted or
is unmarked for backup. This way the backup granularity can be controlled by
the user in the time between backup snapshots.
just an idea, possible? problems?
With regards,
Reinoud
next prev parent reply other threads:[~2009-03-12 15:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-01 0:57 Dump tools for checkpoints nilfs-MZZvbRqs/9F0RdzJJlgK+g
[not found] ` <2883.84.133.202.72.1235869032.squirrel-lZV7jZi4TBeO2lRZCxuEEg@public.gmane.org>
2009-03-08 5:39 ` Ryusuke Konishi
[not found] ` <20090308.143916.113539820.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-03-12 15:26 ` Reinoud Zandijk [this message]
[not found] ` <20090312152618.GA25317-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-03-13 15:33 ` Ryusuke Konishi
2009-03-13 16:26 ` Leon Weber
[not found] ` <20090313162609.GD7494-Tv691C15nu5348sJH/KcYBvVK+yQ3ZXh@public.gmane.org>
2009-03-13 16:53 ` Gergely Gábor
2009-03-13 17:33 ` mail-MZZvbRqs/9F0RdzJJlgK+g
[not found] ` <3214.84.133.153.87.1236965583.squirrel-lZV7jZi4TBeO2lRZCxuEEg@public.gmane.org>
2009-03-16 0:57 ` Ryusuke Konishi
2009-03-15 13:58 ` Ryusuke Konishi
2009-03-13 16:42 ` nilfs-MZZvbRqs/9F0RdzJJlgK+g
[not found] ` <2893.84.133.153.87.1236962534.squirrel-lZV7jZi4TBeO2lRZCxuEEg@public.gmane.org>
2009-03-15 15:12 ` Ryusuke Konishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090312152618.GA25317@aardappel.13thmonkey.org \
--to=reinoud-s783fymb3ccdnm+yrofe0a@public.gmane.org \
--cc=nilfs-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org \
--cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox