From: Oystein Viggen <oysteivi@tihlde.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs problems and fedora 14
Date: Fri, 26 Nov 2010 11:11:28 +0100 [thread overview]
Message-ID: <03d3ps1jjj.fsf@msgid.viggen.net> (raw)
In-Reply-To: 1290764456.4380.20.camel@main-wireless
* [david grant]=20
> BUT I am still left with the problem that caused it for me: how do I
> backup (clone?) a btrfs file system with snapshots to another btrfs
> partition (apart from using dd). I just hope I don't get scolded agai=
n
> and told I am not up to it.
I don't think you can conveniently clone the filesystem including the
snapshots to another computer or partition using traditional userspace
tools like tar or rsync, since they'd end up de-linking the reflink-nes=
s
of the snapshots, so that all the snapshots end up taking the full
space.
However, I can think of one or two strategies that might help you
achieve something close to what you actually want:
1. If the snapshots are just for "online backup", you could backup only
what you consider the live subvol (or even better: a very recent
snapshot of it), and then make snapshots on the target filesystem after
each backup. While this isn't really a backup including the snapshots,
it might serve the purpose you want.
2. You could rsync the oldest snapshot, make a snapshot of it on the
target filesystem named the same as your second-oldest snapshot, rsync
(--inplace) the second-oldest snapshot into that newly created snapshot=
,
and repeat until you've done all the snapshots. My head is already
spinning, but it seems to me that it should be possible to automate thi=
s
in a not-too-ugly shell script that also handles updates in a sane way.
This falls to bits, however, if the various snapshots are regularly
written to, or if you can't be sure of their creation order. (for date=
d
backup snapshots, there shouldn't be a problem).
What would be really awesome is some sort of "btrfs-send" program that
handles all this the best way for you, but I don't think that exists
(yet). User friendly tools will undoubtedly appear as btrfs is more
used, but I guess it's still partly in the "roll your own" early adopte=
r
stage. :)
=D8ystein
--=20
"Windows is too dangerous to be left to Windows admins."
-- James Riden in the monastery
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-11-26 10:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 23:19 btrfs problems and fedora 14 david grant
2010-11-22 23:28 ` Hugo Mills
2010-11-23 4:47 ` Wenyi Liu
2010-11-23 6:45 ` C Anthony Risinger
2010-11-24 7:32 ` david grant
2010-11-24 9:19 ` cwillu
2010-11-26 9:40 ` david grant
2010-11-26 10:11 ` Oystein Viggen [this message]
2010-11-26 10:36 ` David Pottage
2010-11-26 17:47 ` cwillu
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=03d3ps1jjj.fsf@msgid.viggen.net \
--to=oysteivi@tihlde.org \
--cc=linux-btrfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.