Re: [Duplicity-talk] How to use duplicity for local backup

[edgar . soldin]

hi MRob,

On 24.04.2020 19:50, MRob via Duplicity-talk wrote:
> Hello, I want to ask opinion about backup tactic please.
>
> I found a backup system that using only rsync to a local server. A few 
> scripts run on the server that create tree of historical directrories that 
> are filled with hard links to the main rsync target. I never saw this but my 
> understand of the benefit:
> * saving space for historical backups because they only use inodes
> * simple scheme to use rsync and ln

off-topic but interestingly there is a popular backup strategy like that.

on the backend (where the backups are stored)
- create mirror/snapshot of the last backup folder (eg. using file systems like 
btrfs, zfs or using 'rsync --link-dest=...' below)
on the backend or locally
- run rsync and synchronize the new backend folder
repeat

using cow(copy-on-write) filesystem you can even have rsync not to create a new 
file but just replace chunks of big ones, saving even more space.

> * But am I correct, to understand if a file *change* then the historical data 
> is lost so its a shortcoming of the scheme.

not necessarily as rsync by default creates a new file if it detected changes 
in the old one, hence your old hardlinks won't be touched in that case

> Is this scheme popular?

relatively. i for one use it in some places.

>Is it useful in comparison to local-rsync variation of duplicity?

not comparable to what duplicity does. duplicity creates final volumes of 
backup data that are merely dumped on some backend.

>For example, lower CPU needed because not creating archive files and 
>encrypting them.

as said. completely different approach. you need eg. a backend that you trust 
your unencrypted data with.

>Can duplicity have gpg turn off when it is not necessary?

yes. but then you may as well check out thy myriad of backup solutions out 
there. one might be a better fit for you.

>I prefer duplicity to replace the scheme but have limited storage and limited 
>CPU cycles.

why, if it is working now?

> Could you guide to help make duplicity a comparable option in that context? 
> Thank you.

again, not comparable sorry.


have fun ..ede/duply.net