restic / caddy

A plugin for the Caddy web server to act as a backend for restic

Introduction

restic is a backup program that is fast, efficient and secure. It supports the three major operating systems (Linux, macOS, Windows) and a few smaller ones (FreeBSD, OpenBSD).

For detailed usage and installation instructions check out the documentation.

You can ask questions in our Discourse forum.

Quick start

Once you've installed restic, start off with creating a repository for your backups:

$ restic init --repo /tmp/backup
enter password for new backend:
enter password again:
created restic backend 085b3c76b9 at /tmp/backup
Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.

and add some data:

$ restic --repo /tmp/backup backup ~/work
enter password for repository:
scan [/home/user/work]
scanned 764 directories, 1816 files in 0:00
[0:29] 100.00%  54.732 MiB/s  1.582 GiB / 1.582 GiB  2580 / 2580 items  0 errors  ETA 0:00
duration: 0:29, 54.47MiB/s
snapshot 40dc1520 saved

Next you can either use restic restore to restore files or use restic mount to mount the repository via fuse and browse the files from previous snapshots.

For more options check out the online documentation.

Backends

Saving a backup on the same machine is nice but not a real backup strategy. Therefore, restic supports the following backends for storing backups natively:

• Local directory
• sftp server (via SSH)
• HTTP REST server (protocol, rest-server)
• Amazon S3 (either from Amazon or using the Minio server)
• OpenStack Swift
• BackBlaze B2
• Microsoft Azure Blob Storage
• Google Cloud Storage
• And many other services via the rclone Backend

Design Principles

Restic is a program that does backups right and was designed with the following principles in mind:

• Easy: Doing backups should be a frictionless process, otherwise you might be tempted to skip it. Restic should be easy to configure and use, so that, in the event of a data loss, you can just restore it. Likewise, restoring data should not be complicated.

• Fast: Backing up your data with restic should only be limited by your network or hard disk bandwidth so that you can backup your files every day. Nobody does backups if it takes too much time. Restoring backups should only transfer data that is needed for the files that are to be restored, so that this process is also fast.

• Verifiable: Much more important than backup is restore, so restic enables you to easily verify that all data can be restored.

• Secure: Restic uses cryptography to guarantee confidentiality and integrity of your data. The location the backup data is stored is assumed not to be a trusted environment (e.g. a shared space where others like system administrators are able to access your backups). Restic is built to secure your data against such attackers.

• Efficient: With the growth of data, additional snapshots should only take the storage of the actual increment. Even more, duplicate data should be de-duplicated before it is actually written to the storage back end to save precious backup space.

Reproducible Builds

The binaries released with each restic version starting at 0.6.1 are reproducible, which means that you can reproduce a byte identical version from the source code for that release. Instructions on how to do that are contained in the builder repository.

News

You can follow the restic project on Mastodon @resticbackup or subscribe to the project blog.

License

Restic is licensed under BSD 2-Clause License. You can find the complete text in LICENSE.

Sponsorship

Backend integration tests for Google Cloud Storage and Microsoft Azure Blob Storage are sponsored by AppsCode!

caddy's Issues

Register plugin for caddy

I've roughly looked at the process:

• We need to open a PR for caddy to correct the URL https://github.com/mholt/caddy/blob/7b5efb5d7581e7c6f04f000369708f5cf25e10f4/caddyhttp/httpserver/plugin.go#L498
• Register the plugin
• Tag a release so that the website includes it as an option

caddy v1.0.3 build not working, because of missing release with latest commit

The release 1.0.3 of caddy does not with github.com/restic/caddy, because the commit d755491 is missing in the latest release.

add support for append-only option

I didn't find a way to use the option --append-only from the last rest-server in this plugin.
Having feature parity between server and plugin would be great.

Plugin not working correctly in a multisite configuration

I might be something incorrectly, but here's my Caddy config file.

https://example.com/backups/repo1 {

	tls {
        	dns cloudflare
	}

	basicauth user pass {
        	/
	}

	restic / /home/backups/repo1

}



https://example.com/backups/repo2 {

	tls {
        	dns cloudflare
	}

	basicauth user pass {
        	/
	}

	restic / /home/backups/repo2

}


https://example.com/backups/repo3 {

	tls {
        	dns cloudflare
	}

	basicauth user pass {
        	/
	}

	restic / /home/backups/repo3

}

I can access all virtual paths, however it only writes to the physical path of the last site configured with restic.

So I can connect to repo1, repo2, and repo3 fine, but it all attempts to save under repo3.

Incompatible with caddy 1.0.0+

This plugin breaks a caddy build with the following message:

.go/pkg/mod/github.com/restic/[email protected]/setup.go:19:16: undefined: restserver.Server
.go/pkg/mod/github.com/restic/[email protected]/setup.go:42:19: undefined: restserver.NewHandler

The issue is maybe related to caddy requiring Go modules to build since its 1.0.0. Introducing modules support is quite easy, simply run go mod init github.com/restic/caddy in the root of your repository and commit go.sum and go.mod that are created by the aforementioned command.

Caddy's import path has changed

(I know I could change this myself in a jiffy -- I'm just filing issues for as many plugins as I can, then I can come back and make a commit if someone doesn't beat me to it.)

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

to

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.