From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: Hugo Mills <hugo@carfax.org.uk>,
Piotr Szymaniak <szarpaj@grubelek.pl>,
Andrei Borzenkov <arvidjaar@gmail.com>,
Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: Cloning / getting a full backup of a BTRFS filesystem
Date: Wed, 4 Sep 2019 23:04:08 +0200 [thread overview]
Message-ID: <5b5cc1fd-1e68-53c5-97bd-876c5cf08683@petaramesh.org> (raw)
In-Reply-To: <CAJCQCtQoKOL68yMWSBfeDKsp4qCci1WQiv4YwCpf15JWF++upg@mail.gmail.com>
Hello and thanks for the replies all,
Le 04/09/2019 à 22:48, Chris Murphy a écrit :
> If you want an exact copy, including all of the exact UUIDs, yes.
No I don"t really care about the UUIDs, and it's the only thing I don't
care about.
My use case is rather taking a full and complete copy of my NAS BTRFS
RAID-5 storage space onto an external, eventually big, disk, or some
other RAID combination in case something would go wrong - in a way that
I could get everything backed up and restored easily.
So far and for years I found BTRFS to be extremely reliable and
resilient in all configurations, but I've had several issues with recent
5.1 and 5.2 kernels on several machines recently .
My NAS holds a number of subvols for many different purposes, most of
them contains a hosts of RO snaphots made either manually or
automatically using snapper, and everything is offline-deduped using
bees (as there is a *lot* of redundant copies of the same files in
different subvols and structures).
Of course I cannot just “dd” as I don't start from a single device but a
BTRFS RAID, and I'm afraid that any manual scheme that I could think of
would break deduplication and thus result in a huge output that wouldn't
fit any device I could think of.
So the question reslly is : How could I backup a complex BTRFS volume to
another but differently (physically) organized volume keeping the
complete structure and being able to restore it preferably in a single
operation.
If the answer is « There's no way it can be done » then it is really
badly annoying...
ॐ
--
Swâmi Petaramesh <swami@petaramesh.org> PGP 9076E32E
next prev parent reply other threads:[~2019-09-04 21:04 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
2019-09-04 20:20 ` Hugo Mills
2019-09-04 20:48 ` Chris Murphy
2019-09-04 21:04 ` Swâmi Petaramesh [this message]
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=5b5cc1fd-1e68-53c5-97bd-876c5cf08683@petaramesh.org \
--to=swami@petaramesh.org \
--cc=arvidjaar@gmail.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=szarpaj@grubelek.pl \
/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.