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. It must be specified on the backup destination side. To specify it from the client side, you need you need the --remote-option= option. That option is only available in rsync 3.1.0 and later. The first Ubuntu or Mint LTS that has that version is 14.04/17.

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-dest seems to figure out its directory on the machine that's running the rsync. Not very useful. However, if you use the --remote-option=--link-dest=..., then it works.

--delete-missing-args may be the way to delete the old backups from the client. Deletes a specific name from the destination system, even if file doesn't exist on the source system.

TODO.

Permissions

--super and --fake-super seem to have no effect on the sending side, with respect to being able to back up a file owned by root and not readable. Running the backup with sudo sends the file across and it has the right permissions on the other side, with no special arguments.

Restoring without sudo leaves the files as owned by me, and therefore readable! That's not very secure! I expect it's because we're authenticating with admin on the receiving end. That's why we can both write it and set it to root on the destination, and why it comes back.

Restoring with sudo leaves files with the right permissions.

It's possible that --fake-super really does fake being super user, but when you restore, you get the original attributes back. Perhaps the idea is that you copy the files to somewhere with --fake-super, then copy them back with super-user privileges to restore the permissions. This would allow different users for each backup, who can't see each other's backups, but can store permissions and owners.

rsync reads its .conf file every time someone connects to the daemon. I think I only had to restart the daemon the first time I added something to the default .conf file.

Configuration

Even though I didn't have a lot of machines using Simbur, when I moved to a new Synology it was tedious to make the configuration changes, specifically the destination, account, and password. I also discovered that I may want to change some of the include and exclude configurations.

Some of this could be handled by new versions of the package:

• Split the configs into a simbur-client.conf file and a simbur-client.d directory where per-machine configuration lies.
• Investigate whether further refactoring of the configuration is needed -- maybe the distribution includes some files in simbur-client.d or some other way for the site-specific-but-common configuration.
• A local super-simple .deb to configure the site-specific-but-common configuration.