Design

Pull model overview

Introduction

The idea is to allow a resticprofile instance (the server) to send a request to a client to backup some data to some location.

This is some kind of pull model: where a server connects to client to backup its data. In reality, the server sends a command that will push a backup to a remote server. But in the end we still get a centralized model for our backups.

Assumptions and Dependencies

The client

• should have SSH installed, with the SFTP subsystem available
• should have private key authentication configured (no password authentication)
• doesn't need to have anything else installed (no restic, no resticprofile, no rsync)
• doesn't even need to have any configuration profile, or repository keys installed either

The server is probably going to be a separate binary, with a slightly different configuration file.

Configuration

The resticprofile server will need this configuration for each SSH connection (client):

• IP address
• SSH port
• Username
• SSH Private key (no password authentication)
• name of the profile(s) and command(s) to run

Optional:

• Client SSH signature (use OpenSSH known_hosts by default)
• Working directory (use tmpfs if we delete the keys afterwards)
• TCP port to forward (in case the client doesn't have direct access to the repository) - it could be dynamically generated
• Option to leave or delete the configuration profile and repository key on the client machine (which allow restoring files without the need of the server)
• Option to send logs to the standard output (back to the server) or store them locally and send them at the end (SFTP)

Model

The server

1. initiates a SSH connection with a client
2. checks if restic and resticprofile binaries are available (and which version)
3. instructs the client to install or update restic and/or resticprofile if not installed
4. sends the configuration profile along with the repository key (via SFTP)
5. runs the resticprofile profile command(s)
6. deletes the configuration profile and repository key (but leaves the binaries behind)
7. closes the SSH connection when it's finished

The output logs can be sent through the SSH output pipe back to the instance who initiated the connection (server), or they can be stored locally and copied back to the server using SFTP once finished.

Questions

• Which name for the separate program? resticcommander sounds like a good choice to keep the same unreadability :)
• Is the default to leave or to delete configuration and keys? (probably leave)
• When using a template on a profile, where should the template be resolved, on the client or on the server?
• How do we want to handle deployment (and updates) of restic and/or resticprofile? (security concerns)
• The server can run as a daemon, or triggered by systemd/crond.