add pre+post-backup commands

[freisei]

What should rest-server do differently?

add the ability to execute some commands just before and after the backup happens.

Example for doc:
--pre-backup-cmd execute a command/script just before the restic backup is executed (before any data are written)
--post-backup-cmd execute a command/script after the restic backup from remote is finished

What are you trying to do? What is your use case?

I would like to use rest-server for security-reasons. Mainly to avoid to get rid of the backups if a client is hacked. So i use the --append-only-command.

My old backup-scripts have done some preparing (i.E. creating statistics of usage before and after a backup, creating snapshots, creating index for a self-created http-restore-gui). This was executed by ssh on the restic-server.

In future i want to avoid ssh-access from client due to security reasons, but i need to execute my pre- and post-backupscripts.

I could write a own rest-server which does exaclty this, but i think i am not the only one who needs this and all of the infrastructure of restic-rest-server could be used (auth, encryption etc)

Did rest-server help you today? Did it make you happy in any way?

it made my happy just of beeing existent and i can solve my security-problems :)

[wojas]

The rest-server does not know when a backup has ended. The protocol is stateless and any changes are driven by the client manipulating objects. There can also be more than one client updating the same repository at the same time.

If we were to implement something like this, it would probably have to rely on heuristics like "run after 5 minutes of no new activity". But how would this be better than just running a cronjob to do any periodic maintenance? There is nothing that prevents a client from accessing the repo during this maintenance task anyway.

[dionorgua]

It's actually pretty easy to make reasonable good assumption about backup start/end:

• backup start -- first write request from client
• backup end -- snapshot file is created and lock file removed

Most of these stuff can be easily implemented using some file monitoring services like incron or systemd unit

[freisei]

it would be no problem from my side to trigger the rest-server to execute the pre- or postcommands.
something like curl https://user:pass@10.10.10.2:8000/pre-script
Maybe this would even be a fine way, so i can get a exit-value and then decide to do the actual backup or something else.

[wojas]

Explicit triggers could be useful, for example by calling something like POST /some-repo/trigger?name=pre-backup.

Restic could perhaps be extended to perform some specific calls like pre-backup and post-backup and perhaps gain an extra command to manually trigger custom triggers. It would ignore 404 errors on these calls.

The actual commands to be executed could be configured in a config file (#139).

Is this something we would like to add?

Any volunteer to do the work?

[freisei]

for security reasons restic should allow only pre-defined (by config or command-line) commands. Never allow custom commands to be executed because if the client is hacked, the hacker can execute any command on backup-server which proberbly noone wants :)

[freisei]

Is this something we would like to add?

me of course :)

Any volunteer to do the work?

I don't have the ability to do this. But I can write manuals/documentations for this issue.

[MichaelEischer]

It's actually pretty easy to make reasonable good assumption about backup start/end:

* backup start -- first write request from client

* backup end -- snapshot file is created and lock file removed

That cannot work. On the protocol level a "backup start" is not really distinguishable e.g. from prune. And a backup end just looks the same as copy or soon rewrite.

Restic could perhaps be extended to perform some specific calls like pre-backup and post-backup and perhaps gain an extra command to manually trigger custom triggers. It would ignore 404 errors on these calls.

I don't see why this would have to be integrated into restic, why not a simple separate web server? I'm not at all convinced of adding such extra functionality which only works for a single backend. With the initially mentioned use case, a proper integration into restic would also affect lots of other commands besides the backup command. For proper statistics e.g. the copy and prune command would also have to be adjusted.

Btw, there is no way to guarantee that post-backup is called if pre-backup was called earlier on. If restic crashes / the network connection is interrupted, then post-backup won't be called.

[freisei]

what about the manual triggering?

[MichaelEischer]

what about the manual triggering?

That would still only work for the rest backend. And would also be doable using a one-line curl command (the client side)

[Edit]Why not simply use a cron job at the server side which checks for new snapshots? Or maybe even us inotify to learn about new snapshots faster.[/Edit]

[freisei]

i meant not the triggering itself, of course this can be done with curl. But triggering does not make sense if the server has no ability to be triggered and then execute some commands.
That would still only work for the rest backend
Of course. Thats why i opened a issue in rest-server not in restic.

If i am the only one who thinks this is useful, i can make my own solution out of restic-rest-server. I just thougt like my initial comment shows.