From: Piotr Szymaniak <szarpaj@grubelek.pl>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: "Swâmi Petaramesh" <swami@petaramesh.org>,
"Linux BTRFS Mailinglist" <linux-btrfs@vger.kernel.org>,
"Michel Bouissou" <michel@bouissou.net>
Subject: Re: Cloning / getting a full backup of a BTRFS filesystem
Date: Wed, 4 Sep 2019 16:04:44 +0200 [thread overview]
Message-ID: <20190904140444.GH31890@pontus.sran> (raw)
In-Reply-To: <CAA91j0VLnOB1pZAbi-Gr2sNUJMj56LbBU7=NLYGfrPs7T_GpNA@mail.gmail.com>
On Wed, Sep 04, 2019 at 12:03:10PM +0300, Andrei Borzenkov wrote:
> On Wed, Sep 4, 2019 at 9:16 AM Swâmi Petaramesh <swami@petaramesh.org> wrote:
> >
> > Hi list,
> >
> > Is there an advised way to completely “clone” a complete BTRFS
> > filesystem, I mean to get an exact copy of a BTRFS filesystem including
> > subvolumes (even readonly snapshots) and complete file attributes
> > including extended attributes, ACLs and so, to another storage pool,
> > possibly defined with a different RAID geometry or compression ?
> >
>
> As long as you do not use top level subvolume directly (all data is
> located in subolumes), send/receive should work.
>
> > The question boils down to getting an exact backup replica of a given
> > BTRFS filesystem that could be restored to something logically
> > absolutely identical.
> >
> > The usual backup tools have no clue about share extents, snapshots and
> > the like, and using btrfs send/receive for individual subvols is a real
> > pain in a BTRFS filesystem that may contain hundreds of snapshots of
> > different BTRFS subvols plus deduplication etc.
> >
>
> Shared extents could be challenging. You can provide this information
> to "btrfs send", but for one, there is no direct visibility into which
> subvolumes share extents with given subvolume, so no way to build
> corresponding list for "btrfs send". I do not even know if this
> information can be obtained without exhaustive search over all
> extents. Second, btrfs send/receive only allows sharing of full
> extents which means there is no guarantee of identical structure on
> receiving side.
So right now the only answer is: use good old dd?
Piotr Szymaniak.
--
Jedyne napisy, które rozumie każdy Amerykanin, to "Wyprzedaż", "Za
darmo" i "Seks". Kiedyś widziałem w Arizonie tablicę "Seks za darmo.
Ograniczenie prędkości do 60 km/h".
-- Nelson DeMille, "The Lion's Game"
next prev parent reply other threads:[~2019-09-04 20:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 6:15 Cloning / getting a full backup of a BTRFS filesystem Swâmi Petaramesh
2019-09-04 9:03 ` Andrei Borzenkov
2019-09-04 14:04 ` Piotr Szymaniak [this message]
2019-09-04 20:20 ` Hugo Mills
2019-09-04 20:48 ` Chris Murphy
2019-09-04 21:04 ` Swâmi Petaramesh
2019-09-04 22:01 ` Chris Murphy
2019-09-04 22:14 ` Alberto Bursi
2019-09-05 2:47 ` Chris Murphy
2019-09-05 4:59 ` Swâmi Petaramesh
2019-09-04 17:55 ` Chris Murphy
2019-09-04 20:51 ` Chris Murphy
2019-09-05 13:06 ` Anand Jain
2019-09-05 13:13 ` Qu Wenruo
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=20190904140444.GH31890@pontus.sran \
--to=szarpaj@grubelek.pl \
--cc=arvidjaar@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=michel@bouissou.net \
--cc=swami@petaramesh.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.