New Implementation

Overview

The new implementation is still client server, with the client still doing most of the work.

The motivation is to be able to use my DSM storage box as the server, without messing with its default set-up too much. It comes with an easy to enable rsync server already. I suspect that using the rsync server approach, rather than rsync over ssh approach, might solve some of my permission issues. (Although I would still want to use SSH protocol if the backups were over a public network.)

I've also discovered that there's a --link-dest=DIR option that does much of the hard-link work.

I'm thinking that the pruning might legitimately be a server task.

[May sure rsync is transferring numeric uid and gid -- or at least confirm that that's not what I want.]

I think it would be good to build the restore client at the same time. It will help force my thinking to where the value is, and will facilitate testing.

Restore

Initially, restore can be run privileged, so it can connect with the same credentials as would be used for the backup.

Restore needs to know:

• The file or directory to restore
• An optional destination, defaulting to /tmp, unless overwrite is explicitly set (e.g. with a flag)
• An optional "as-of" date, defaulting to the most recent backup

Restore implies a "backup ls".

Backup

The trick about using something like DSM is that I don't want to have to write a package for every possible backup device. The client should be able to set up and talk to a fairly generic rsync server and be done with it. Probably a stretch goal given user creation, etc., but whatever.

The is a --link-dest=DIR argument to hard link to the directory if the file is unchanged. --link-dest, --copy-dest, and --compare-dest are mutually exclusive.

--link-desk seems to figure out its directory on the machine that's running the rsync. Not very useful.

TODO.