$ ./restic --help
restic is a backup program which allows saving multiple revisions of files anddirectories in an encrypted repository stored on different backends.Usage: restic [command]Available Commands: autocomplete Generate shell autocompletion script backup Create a new backup of files and/or directories cat Print internal objects to stdout check Check the repository for errors dump Dump data structures find Find a file or directory forget Remove snapshots from the repository help Help about any command init Initialize a new repository key Manage keys (passwords) list List items in the repository ls List files in a snapshot mount Mount the repository prune Remove unneeded data from the repository rebuild-index Build a new index file restore Extract the data from a snapshot snapshots List all snapshots tag Modify tags on snapshots unlock Remove locks other processes created version Print version informationFlags: --json set output mode to JSON for commands that support it --no-lock do not lock the repo, this allows some operations on read-only repos -p, --password-file string read the repository password from a file -q, --quiet do not output comprehensive progress report -r, --repo string repository to backup to or restore from (default: $RESTIC_REPOSITORY)Use "restic [command] --help" for more information about a command.

Similar to programs such as git, restic has a number of
sub-commands. You can see these commands in the listing above. Each
sub-command may have own command-line options, and there is a help
option for each command which lists them, e.g. for the backup
command:

$ ./restic backup --help
The "backup" command creates a new snapshot and saves the files and directoriesgiven as the arguments.Usage: restic backup [flags] FILE/DIR [FILE/DIR] ...Flags: -e, --exclude pattern exclude a pattern (can be specified multiple times) --exclude-file string read exclude patterns from a file --files-from string read the files to backup from file (can be combined with file args) -f, --force force re-reading the target files/directories. Overrides the "parent" flag -x, --one-file-system Exclude other file systems --parent string use this parent snapshot (default: last snapshot in the repo that has the same target files/directories) --stdin read backup from stdin --stdin-filename string file name to use when reading from stdin --tag tag add a tag for the new snapshot (can be specified multiple times) --time string time of the backup (ex. '2012-11-01 22:08:41') (default: now)Global Flags: --json set output mode to JSON for commands that support it --no-lock do not lock the repo, this allows some operations on read-only repos -p, --password-file string read the repository password from a file -q, --quiet do not output comprehensive progress report -r, --repo string repository to backup to or restore from (default: $RESTIC_REPOSITORY)

Subcommand that support showing progress information such as backup,
check and prune will do so unless the quiet flag -q or
--quiet is set. When running from a non-interactive console progress
reporting will be limited to once every 10 seconds to not fill your
logs.

Additionally on Unix systems if restic receives a SIGUSR signal the
current progress will written to the standard output so you can check up
on the status at will.

Other backends like sftp and s3 are described in the following
sections.

Remembering your password is important! If you lose it, you won’t be
able to access data stored in the repository.

For automated backups, restic accepts the repository location in the
environment variable RESTIC_REPOSITORY. The password can be read
from a file (via the option --password-file) or the environment
variable RESTIC_PASSWORD.

In order to backup data via SFTP, you must first set up a server with
SSH and let it know your public key. Passwordless login is really
important since restic fails to connect to the repository if the server
prompts for credentials.

Once the server is configured, the setup of the SFTP repository can
simply be achieved by changing the URL scheme in the init command:

You can also specify a relative (read: no slash (/) character at the
beginning) directory, in this case the dir is relative to the remote
user’s home directory.

The backend config string does not allow specifying a port. If you need
to contact an sftp server on a different port, you can create an entry
in the ssh file, usually located in your user’s home directory at
~/.ssh/config or in /etc/ssh/ssh_config:

HostfooUserbarPort2222

Then use the specified host name foo normally (you don’t need to
specify the user name in this case):

$ restic -r sftp:foo:/tmp/backup init

You can also add an entry with a special host name which does not exist,
just for use with restic, and use the Hostname option to set the
real host name:

Hostrestic-backup-hostHostnamefooUserbarPort2222

Then use it in the backend specification:

$ restic -r sftp:restic-backup-host:/tmp/backup init

Last, if you’d like to use an entirely different program to create the
SFTP connection, you can specify the command to be run with the option
-osftp.command="foobar".

In order to backup data to the remote server via HTTP or HTTPS protocol,
you must first set up a remote REST
server instance. Once the
server is configured, accessing it is achieved by changing the URL
scheme like this:

$ restic -r rest:http://host:8000/

Depending on your REST server setup, you can use HTTPS protocol,
password protection, or multiple repositories. Or any combination of
those features, as you see fit. TCP/IP port is also configurable. Here
are some more examples:

If you use TLS, make sure your certificates are signed, ‘cause restic
client will refuse to communicate otherwise. It’s easy to obtain such
certificates today, thanks to free certificate authorities like Let’s
Encrypt.

REST server uses exactly the same directory structure as local backend,
so you should be able to access it both locally and via HTTP, even
simultaneously.

Restic can backup data to any Amazon S3 bucket. However, in this case,
changing the URL scheme is not enough since Amazon uses special security
credentials to sign HTTP requests. By consequence, you must first setup
the following environment variables with the credentials you obtained
while creating the bucket.

It is not possible at the moment to have restic create a new bucket in a
different location, so you need to create it using a different program.
Afterwards, the S3 server (s3.amazonaws.com) will redirect restic to
the correct endpoint.

For an S3-compatible server that is not Amazon (like Minio, see below),
or is only available via HTTP, you can specify the URL to the server
like this: s3:http://server:port/bucket_name.

Restic can backup data to an OpenStack Swift container. Because Swift supports
various authentication methods, credentials are passed through environment
variables. In order to help integration with existing OpenStack installations,
the naming convention of those variables follows official python swift client:

Once environment variables are set up, a new repository can be created. The
name of swift container and optional path can be specified. If
the container does not exist, it will be created automatically:

Restic supports Google Cloud Storage as a backend. In order for this to work
you first need create a “service account” and download the JSON key file for
it. In addition, you need the Google Project ID that you can see in the Google
Cloud Platform console at the “Storage/Settings” menu. Export the path to the
JSON credentials file and the project ID as follows:

At the moment, restic only supports the default Windows console
interaction. If you use emulation environments like
MSYS2 or
Cygwin, which use terminals like
Mintty or rxvt, you may get a password error:

You can workaround this by using a special tool called winpty (look
here and
here for detail information).
On MSYS2, you can install winpty as follows:

Now we’re ready to backup some data. The contents of a directory at a
specific point in time is called a “snapshot” in restic. Run the
following command and enter the repository password you chose above
again:

In fact several hosts may use the same repository to backup directories
and files leading to a greater de-duplication.

Please be aware that when you backup different directories (or the
directories to be saved have a variable name component like a
time/date), restic always needs to read all files and only afterwards
can compute which parts of the files need to be saved. When you backup
the same directory again (maybe with new or changed files) restic will
find the old snapshot in the repo and by default only reads those files
that are new or have been modified since the last snapshot. This is
decided based on the modify date of the file in the file system.

You can exclude folders and files by specifying exclude-patterns. Either
specify them with multiple --exclude‘s or one --exclude-file

By specifying the option --one-file-system you can instruct restic
to only backup files from the file systems the initially specified files
or directories reside on. For example, calling restic like this won’t
backup /sys or /dev on a Linux system:

$ restic -r /tmp/backup backup --one-file-system /

By using the --files-from option you can read the files you want to
backup from a file. This is especially useful if a lot of files have to
be backed up that are not in the same folder or are maybe pre-filtered
by other software.

For example maybe you want to backup files that have a certain filename
in them:

$ find /tmp/somefiles | grep 'PATTERN' > /tmp/files_to_backup

You can then use restic to backup the filtered files:

$ restic -r /tmp/backup backup --files-from /tmp/files_to_backup

Incidentally you can also combine --files-from with the normal files
args:

Sometimes it can be nice to directly save the output of a program, e.g.
mysqldump so that the SQL can later be restored. Restic supports
this mode of operation, just supply the option --stdin to the
backup command like this:

$ mysqldump [...]| restic -r /tmp/backup backup --stdin

This creates a new snapshot of the output of mysqldump. You can then
use e.g. the fuse mounting option (see below) to mount the repository
and read the file.

By default, the file name stdin is used, a different name can be
specified with --stdin-filename, e.g. like this:

Note the snapshot ID has changed, so between each change we need to look
up the new ID of the snapshot. But there is an even better way, the
tag command accepts --tag for a filter, so we can filter
snapshots based on the tag we just added.

Mounting repositories via FUSE is not possible on Windows and OpenBSD.

Restic supports storage and preservation of hard links. However, since
hard links exist in the scope of a filesystem by definition, restoring
hard links from a fuse mount should be done by a program that preserves
hard links. A program that does so is rsync, used with the option
–hard-links.

All backup space is finite, so restic allows removing old snapshots.
This can be done either manually (by specifying a snapshot ID to remove)
or by using a policy that describes which snapshots to forget. For all
remove operations, two commands need to be called in sequence:
forget to remove a snapshot and prune to actually remove the
data that was referenced by the snapshot from the repository. This can
be automated with the --prune option of the forget command,
which runs prune automatically if snapshots have been removed.

Removing snapshots manually is tedious and error-prone, therefore restic
allows specifying which snapshots should be removed automatically
according to a policy. You can specify how many hourly, daily, weekly,
monthly and yearly snapshots to keep, any other snapshots are removed.
The most important command-line parameter here is --dry-run which
instructs restic to not remove anything but print which snapshots would
be removed.

When forget is run with a policy, restic loads the list of all
snapshots, then groups these by host name and list of directories. The grouping
options can be set with --group-by, to only group snapshots by paths and
tags use --group-bypaths,tags. The policy is then applied to each group of
snapshots separately. This is a safety feature.

The forget command accepts the following parameters:

--keep-lastn never delete the n last (most recent) snapshots

--keep-hourlyn for the last n hours in which a snapshot was
made, keep only the last snapshot for each hour.

--keep-dailyn for the last n days which have one or more
snapshots, only keep the last one for that day.

--keep-weeklyn for the last n weeks which have one or more
snapshots, only keep the last one for that week.

--keep-monthlyn for the last n months which have one or more
snapshots, only keep the last one for that month.

--keep-yearlyn for the last n years which have one or more
snapshots, only keep the last one for that year.

--keep-tag keep all snapshots which have all tags specified by
this option (can be specified multiple times).

Additionally, you can restrict removing snapshots to those which have a
particular hostname with the --hostname parameter, or tags with the
--tag option. When multiple tags are specified, only the snapshots
which have all the tags are considered. For example, the following command
removes all but the latest snapshot of all snapshots that have the tag foo:

$ restic forget --tag foo --keep-last 1

This command removes all but the last snapshot of all snapshots that have
either the foo or bar tag set:

$ restic forget --tag foo --tag bar --keep-last 1

To only keep the last snapshot of all snapshots with both the tag foo and
bar set use:

$ restic forget --tag foo,tag bar --keep-last 1

All the --keep-* options above only count
hours/days/weeks/months/years which have a snapshot, so those without a
snapshot are ignored.

All snapshots are evaluated counted against all matching keep-* counts. A
single snapshot on 2017-09-30 (Sun) will count as a daily, weekly and monthly.

Let’s explain this with an example: Suppose you have only made a backup
on each Sunday for 12 weeks. Then forget--keep-daily4 will keep
the last four snapshots for the last four Sundays, but remove the rest.
Only counting the days which have a backup and ignore the ones without
is a safety feature: it prevents restic from removing many snapshots
when no new ones are created. If it was implemented otherwise, running
forget--keep-daily4 on a Friday would remove all snapshots!

Another example: Suppose you make daily backups for 100 years. Then
forget--keep-daily7--keep-weekly5--keep-monthly12--keep-yearly75
will keep the most recent 7 daily snapshots, then 4 (remember, 7 dailies
already include a week!) last-day-of-the-weeks and 11 or 12
last-day-of-the-months (11 or 12 depends if the 5 weeklies cross a month).
And finally 75 last-day-of-the-year snapshots. All other snapshots are
removed.

Afterwards, extensive debug messages are written to the file in
environment variable DEBUG_LOG, e.g.:

$DEBUG_LOG=/tmp/restic-debug.log restic backup ~/work

If you suspect that there is a bug, you can have a look at the debug
log. Please be aware that the debug log might contain sensitive
information such as file and directory names.

The debug log will always contain all log messages restic generates. You
can also instruct restic to print some or all debug messages to stderr.
These can also be limited to e.g. a list of source files or a list of
patterns for function names. The patterns are globbing patterns (see the
documentation for path.Glob), multiple
patterns are separated by commas. Patterns are case sensitive.

Printing all log messages to the console can be achieved by setting the
file filter to *:

$DEBUG_FILES=* restic check

If you want restic to just print all debug log messages from the files
main.go and lock.go, set the environment variable
DEBUG_FILES like this:

$DEBUG_FILES=main.go,lock.go restic check

The following command line instructs restic to only print debug
statements originating in functions that match the pattern *unlock*
(case sensitive):

Internally, a repository stores data of several different types
described in the design
documentation.
You can list objects such as blobs, packs, index, snapshots, keys or
locks with the following command:

Restic supports the output of some commands in JSON format, the JSON
data can then be processed by other programs (e.g.
jq). The following example
lists all snapshots as JSON and uses jq to pretty-print the result:

During some operations (e.g. backup and prune) restic uses
temporary files to store data. These files will, by default, be saved to
the system’s temporary directory, on Linux this is usually located in
/tmp/. The environment variable TMPDIR can be used to specify a
different directory, e.g. to use the directory /var/tmp/restic-tmp
instead of the default, set the environment variable like this: