All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lentes, Bernd" <bernd.lentes@helmholtz-muenchen.de>
To: Btrfs ML <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs-subv-backup v0.1b
Date: Tue, 31 Oct 2017 13:40:37 +0100 (CET)	[thread overview]
Message-ID: <973325765.400970.1509453637439.JavaMail.zimbra@helmholtz-muenchen.de> (raw)
In-Reply-To: <cc9e6302-125b-b120-cc45-35a2e12a3d6a@gmail.com>



----- Am 26. Okt 2017 um 15:32 schrieb Austin S. Hemmelgarn ahferroin7@gmail.com:

> As previously mentioned on the list, I've written up a script to back up
> BTRFS subvolume structures in regular file-based backups.  As of right
> now, it's still a bit rough around the edges, but it's cleaned up enough
> that I consider it of at least beta quality, and therefore fit for more
> general testing (and possibly usage).   Aside from the issues and
> limitations listed below in the README, error checking is still somewhat
> lacking, and I plan to remedy that in the near future.
> 
> The script itself can be found here:
> https://github.com/Ferroin/btrfs-subv-backup
> 
> Here's the official README, as that already covers pretty much
> everything else I would put in this e-mail:
> 
> # btrfs-subv-backup v0.1b
> btrfs-subv-backup is a tool for recording the layout of subvolumes on
> a mounted BTRFS filesystem in a way that can be stored in a regular
> file-based backup (for example, using tar).  It originated out of a lack
> of such existing tools, and is intended to be as portable as reasonably
> possible.  As a result, it depends on nothing beyond a working
> installation of Python version 3.4 or higher.
> 
> btrfs-subv-backup is licensed under a BSD-style license, check the
> LICENSE file or the docstring for more information.
> 
> ### Usage
> Usage is extremely simple.  To generate a backup of a given mount
> point, run:
> 
> `btrfs-subv-backup.py /path`
> 
> This will create a file called `.btrfs-subv-backup.json` in the root of
> the mount point, make sure that gets included in any backups you run of
> the mount point.
> 
> To restore the subvolumes in a filesystem after you've extracted a backup
> of the mount point, run:
> 
> `btrfs-subv-backup.py --restore /path`
> 
> This will recreate the subvolume structure.
> 
> If you need to manually recreate the subvolumes, you can find a list
> of them in the aforementioned JSON file under the 'subvolumes' key (the
> other keys store info about the filesystem itself to make it easier to
> figure out what it was).
> 
> ### Limitations and Known Issues
> * We don't store information about reflinks.  This means in particular
> that snapshot relationships __ARE NOT__ saved.  There is currently no
> way to store this data reliably short of a block-level backup, which
> has it's own special issues.
> * Subvolumes with spaces in their name are not supported.
> * There is currently no indication of progress.
> * The restoration process may take a long time, and may use a very large
> amount of disk space.  Ideally this should be fixed, but I'm not sure
> of any way to do so while keeping things on-line.
> * The current restoration process is all-or-nothing, things are not
> correctly handled if some of the subvolumes have already been restored
> (although btrfs-subv-backup will clean up the temporary subvolumes it
> creates during the restore if the restore fails).  This should be pretty
> easy to fix, I just haven't gotten around to it yet.
> * btrfs-subv-backup won't cross actual mount points, which means it
> won't recurse into explicitly mounted subvolumes.  This makes usage a
> bit more complicated on some distributions (such as SLES and OpenSUSE),
> but greatly simplifies the code.

Hi Austin,

thanks for your effort. What are the minimum prerequesties for kernel and btrfsprogs for that script ?
Do you think it will run on my old SLES 11 SP4 ?

ha-idg-1:~ # rpm -qa|grep -i btrfs
btrfsprogs-3.18.2-0.40.48
btrfsmaintenance-0.1-3.1
libbtrfs0-3.18.2-0.40.48

ha-idg-1:~ # uname -a
Linux ha-idg-1 3.0.101-100-default #1 SMP Tue Apr 18 22:46:01 UTC 2017 (ce95309) x86_64 x86_64 x86_64 GNU/Linux

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671


  parent reply	other threads:[~2017-10-31 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-26 13:32 btrfs-subv-backup v0.1b Austin S. Hemmelgarn
2017-10-26 15:25 ` Marat Khalili
2017-10-26 15:55   ` Austin S. Hemmelgarn
2017-10-31 12:40 ` Lentes, Bernd [this message]
2017-10-31 13:59   ` Austin S. Hemmelgarn
2017-10-31 16:54     ` Lentes, Bernd
2017-10-31 17:00       ` Austin S. Hemmelgarn
2017-10-31 19:54         ` Lentes, Bernd
2017-10-31 20:00           ` Austin S. Hemmelgarn

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=973325765.400970.1509453637439.JavaMail.zimbra@helmholtz-muenchen.de \
    --to=bernd.lentes@helmholtz-muenchen.de \
    --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.