All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Marat Khalili <mkh@rqc.ru>
Cc: Dave <davestechshop@gmail.com>,
	Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)
Date: Tue, 14 Nov 2017 13:21:42 +0500	[thread overview]
Message-ID: <20171114132142.2c30cd8e@natsu> (raw)
In-Reply-To: <ebfc86ae-8398-4ecf-d3c9-a0f3e997e9d9@rqc.ru>

On Tue, 14 Nov 2017 10:14:55 +0300
Marat Khalili <mkh@rqc.ru> wrote:

> Don't keep snapshots under rsync target, place them under ../snapshots 
> (if snapper supports this):

> Or, specify them in --exclude and avoid using --delete-excluded.

Both are good suggestions, in my case each system does have its own snapshots
as well, but they are retained for much shorter. So I both use --exclude to
avoid fetching the entire /snaps tree from the source system, and store
snapshots of the destination system outside of the rsync target dirs.

>Or keep using -x if it works, why not?

-x will exclude content of all subvolumes down the tree on the source side --
not only the time-based ones. If you take care to never casually create any
subvolumes content of which you'd still want backed up, then I guess it can
work.

-- 
With respect,
Roman

  reply	other threads:[~2017-11-14  8:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01  5:00 Need help with incremental backup strategy (snapshots, defragmentingt & performance) Dave
2017-11-01  5:15 ` Roman Mamedov
2017-11-01  6:27   ` Dave
2017-11-14  3:39   ` Dave
2017-11-14  7:14     ` Marat Khalili
2017-11-14  8:21       ` Roman Mamedov [this message]
2017-11-14  8:50     ` Roman Mamedov
2017-11-14 20:51       ` Dave
2017-11-16 16:10         ` Kai Krakow
2017-11-16 16:13         ` Kai Krakow
2017-11-17  3:51           ` Andrei Borzenkov
2017-11-17 22:36             ` Kai Krakow
2017-11-01  6:19 ` Marat Khalili
2017-11-01  6:51   ` Dave
2017-11-01  8:34     ` Marat Khalili
2017-11-01 20:27       ` Dave
2017-11-02  0:35         ` Peter Grandi
2017-11-02 20:46     ` Kai Krakow
2017-11-03  3:24       ` Dave
2017-11-03  7:06         ` Kai Krakow

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=20171114132142.2c30cd8e@natsu \
    --to=rm@romanrm.net \
    --cc=davestechshop@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mkh@rqc.ru \
    /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.