From: GEO <1g2e3o4@gmail.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Incremental backup over writable snapshot
Date: Wed, 19 Feb 2014 19:57:03 +0100 [thread overview]
Message-ID: <3285782.sx6x1p7v9y@linuxpc> (raw)
In-Reply-To: <EEA604EA-983B-4F5F-88B5-4FD229FEC61F@colorremedies.com>
On Wednesday 19 February 2014 10:00:49 Chris Murphy wrote:
> On Feb 19, 2014, at 6:45 AM, GEO <1g2e3o4@gmail.com> wrote:
> > I do not like the idea of making subvolumes of all directories I am not
> > interested in backing up.
>
> Why? It addresses your use case.
>
> Chris Murphy
I would prefer the idea of not snapshotting every directory I do not want to
include, as there are almost more that I am not interested in.
My question would simply be: Does the method going over the writeable snapshot
and deleting things always lead to the same incremental end result as marking
directories as snapshots that I am not interested in (apart from the
additional empty directories created in case of the latter)?
Furthermore hidden directories in home change very often, meaning if I install
additional software, additional hidden directories may be created. So my
script would have to mark them as snapshots every time.
If I have hidden files, I cannot mark files as snapshots, so it is clear that my
method makes sense.
Once I have marked these directories snapshots and I want to create snapshots
of my whole home subvolume I would always additionally have to specify those.
So it makes the whole situation less manageable.
Apart from that I find marking every directory I am not interested in as
snapshots highly inelegant.
So my question would be, if my preferred method is as reliable as the
suggested method.
Hope that's on the mailing list now :-).
Thanks
next prev parent reply other threads:[~2014-02-19 18:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 13:45 Incremental backup over writable snapshot GEO
2014-02-19 17:00 ` Chris Murphy
[not found] ` <2285169.jbztTl7OC0@linuxpc>
2014-02-19 17:26 ` Chris Murphy
[not found] ` <16991840.tqyQc6bZHr@linuxpc>
2014-02-19 17:51 ` Chris Murphy
2014-02-19 20:20 ` Kai Krakow
2014-02-20 3:31 ` Kai Krakow
2014-02-20 11:03 ` Duncan
2014-02-20 21:16 ` Kai Krakow
2014-02-21 14:44 ` GEO
2014-02-21 18:56 ` Kai Krakow
2014-02-19 18:57 ` GEO [this message]
2014-02-20 13:20 ` GEO
2014-02-20 23:04 ` Kai Krakow
2014-02-27 13:10 ` GEO
2014-02-28 6:54 ` Duncan
2014-02-27 14:36 ` GEO
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=3285782.sx6x1p7v9y@linuxpc \
--to=1g2e3o4@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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.