forked from TrueCloudLab/restic
doc: Refactors the documentation
This commit refactors the documentation according to my proposal in #1273 and the discussion I had with fd0 on IRC. The bits from the manual that I could not immediately put into the new structure are contained in manual_rest.rst Anything else is still there, nothing has been deleted. I changed the heading markup to follow the convention used in Python’s Style Guide for documentation, this convention is explained in a comment at the top of every file. I also added a paragraph on installing restic on Debian.
This commit is contained in:
parent
3afd974dea
commit
f5b550191c
20 changed files with 1711 additions and 1502 deletions
16
doc/010_introduction.rst
Normal file
16
doc/010_introduction.rst
Normal file
|
@ -0,0 +1,16 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
############
|
||||||
|
Introduction
|
||||||
|
############
|
||||||
|
|
143
doc/020_installation.rst
Normal file
143
doc/020_installation.rst
Normal file
|
@ -0,0 +1,143 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
############
|
||||||
|
Installation
|
||||||
|
############
|
||||||
|
|
||||||
|
Packages
|
||||||
|
********
|
||||||
|
|
||||||
|
Mac OS X
|
||||||
|
========
|
||||||
|
|
||||||
|
If you are using Mac OS X, you can install restic using the
|
||||||
|
`homebrew <http://brew.sh/>`__ package manager:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ brew tap restic/restic
|
||||||
|
$ brew install restic
|
||||||
|
|
||||||
|
Arch Linux
|
||||||
|
==========
|
||||||
|
|
||||||
|
On `Arch Linux <https://www.archlinux.org/>`__, there is a package called ``restic-git``
|
||||||
|
which can be installed from AUR, e.g. with ``pacaur``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ pacaur -S restic-git
|
||||||
|
|
||||||
|
Nix & NixOS
|
||||||
|
===========
|
||||||
|
|
||||||
|
If you are using `Nix <https://nixos.org/nix/>`__ or `NixOS <https://nixos.org/>`__
|
||||||
|
there is a package available named ``restic``.
|
||||||
|
It can be installed uisng ``nix-env``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ nix-env --install restic
|
||||||
|
|
||||||
|
Debian
|
||||||
|
======
|
||||||
|
|
||||||
|
On Debian, there's a package called ``restic`` which can be
|
||||||
|
installed from the official repos, e.g. with ``apt-get``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ apt-get install restic
|
||||||
|
|
||||||
|
|
||||||
|
.. warning:: Please be aware that, at the time of writing, Debian *stable*
|
||||||
|
has ``restic`` version 0.3.3 which is very old. The *testing* and *unstable*
|
||||||
|
branches have recent versions of ``restic``.
|
||||||
|
|
||||||
|
Pre-compiled Binary
|
||||||
|
*******************
|
||||||
|
|
||||||
|
You can download the latest pre-compiled binary from the `restic release
|
||||||
|
page <https://github.com/restic/restic/releases/latest>`__.
|
||||||
|
|
||||||
|
From Source
|
||||||
|
***********
|
||||||
|
|
||||||
|
restic is written in the Go programming language and you need at least
|
||||||
|
Go version 1.8. Building restic may also work with older versions of Go,
|
||||||
|
but that's not supported. See the `Getting
|
||||||
|
started <https://golang.org/doc/install>`__ guide of the Go project for
|
||||||
|
instructions how to install Go.
|
||||||
|
|
||||||
|
In order to build restic from source, execute the following steps:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ git clone https://github.com/restic/restic
|
||||||
|
[...]
|
||||||
|
|
||||||
|
$ cd restic
|
||||||
|
|
||||||
|
$ go run build.go
|
||||||
|
|
||||||
|
You can easily cross-compile restic for all supported platforms, just
|
||||||
|
supply the target OS and platform via the command-line options like this
|
||||||
|
(for Windows and FreeBSD respectively):
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
$ go run build.go --goos windows --goarch amd64
|
||||||
|
|
||||||
|
$ go run build.go --goos freebsd --goarch 386
|
||||||
|
|
||||||
|
The resulting binary is statically linked and does not require any
|
||||||
|
libraries.
|
||||||
|
|
||||||
|
At the moment, the only tested compiler for restic is the official Go
|
||||||
|
compiler. Building restic with gccgo may work, but is not supported.
|
||||||
|
|
||||||
|
Autocompletion
|
||||||
|
**************
|
||||||
|
|
||||||
|
Restic can write out a bash compatible autocompletion script:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ ./restic autocomplete --help
|
||||||
|
The "autocomplete" command generates a shell autocompletion script.
|
||||||
|
|
||||||
|
NOTE: The current version supports Bash only.
|
||||||
|
This should work for *nix systems with Bash installed.
|
||||||
|
|
||||||
|
By default, the file is written directly to ``/etc/bash_completion.d/``
|
||||||
|
for convenience, and the command may need superuser rights, e.g.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ sudo restic autocomplete
|
||||||
|
|
||||||
|
Usage:
|
||||||
|
restic autocomplete [flags]
|
||||||
|
|
||||||
|
Flags:
|
||||||
|
--completionfile string autocompletion file (default "/etc/bash_completion.d/restic.sh")
|
||||||
|
|
||||||
|
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
|
||||||
|
-o, --option key=value set extended option (key=value, can be specified multiple times)
|
||||||
|
-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)
|
||||||
|
|
||||||
|
|
392
doc/030_preparing_a_new_repo.rst
Normal file
392
doc/030_preparing_a_new_repo.rst
Normal file
|
@ -0,0 +1,392 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
##########################
|
||||||
|
Preparing a new repository
|
||||||
|
##########################
|
||||||
|
|
||||||
|
The place where your backups will be saved at is called a "repository".
|
||||||
|
This chapter explains how to create ("init") such a repository.
|
||||||
|
|
||||||
|
Local
|
||||||
|
*****
|
||||||
|
|
||||||
|
In order to create a repository at ``/tmp/backup``, run the following
|
||||||
|
command and enter the same password twice:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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.
|
||||||
|
|
||||||
|
.. warning::
|
||||||
|
|
||||||
|
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_FILE``) or the environment variable ``RESTIC_PASSWORD``.
|
||||||
|
|
||||||
|
SFTP
|
||||||
|
****
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r sftp:user@host:/tmp/backup init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
created restic backend f1c6108821 at sftp:user@host:/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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. note:: Please be aware that sftp servers do not expand the tilde character
|
||||||
|
(``~``) normally used as an alias for a user's home directory. If you
|
||||||
|
want to specify a path relative to the user's home directory, pass a
|
||||||
|
relative path to the sftp backend.
|
||||||
|
|
||||||
|
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``:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
Host foo
|
||||||
|
User bar
|
||||||
|
Port 2222
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
Host restic-backup-host
|
||||||
|
Hostname foo
|
||||||
|
User bar
|
||||||
|
Port 2222
|
||||||
|
|
||||||
|
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
|
||||||
|
``-o sftp.command="foobar"``.
|
||||||
|
|
||||||
|
|
||||||
|
REST Server
|
||||||
|
***********
|
||||||
|
|
||||||
|
In order to backup data to the remote server via HTTP or HTTPS protocol,
|
||||||
|
you must first set up a remote `REST
|
||||||
|
server <https://github.com/restic/rest-server>`__ instance. Once the
|
||||||
|
server is configured, accessing it is achieved by changing the URL
|
||||||
|
scheme like this:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r rest:https://host:8000/
|
||||||
|
$ restic -r rest:https://user:pass@host:8000/
|
||||||
|
$ restic -r rest:https://user:pass@host:8000/my_backup_repo/
|
||||||
|
|
||||||
|
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 <https://letsencrypt.org/>`__.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Amazon S3
|
||||||
|
*********
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export AWS_ACCESS_KEY_ID=<MY_ACCESS_KEY>
|
||||||
|
$ export AWS_SECRET_ACCESS_KEY=<MY_SECRET_ACCESS_KEY>
|
||||||
|
|
||||||
|
You can then easily initialize a repository that uses your Amazon S3 as
|
||||||
|
a backend, if the bucket does not exist yet it will be created in the
|
||||||
|
default location:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r s3:s3.amazonaws.com/bucket_name init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
created restic backend eefee03bbd at s3:s3.amazonaws.com/bucket_name
|
||||||
|
Please note that knowledge of your password is required to access the repository.
|
||||||
|
Losing your password means that your data is irrecoverably lost.
|
||||||
|
|
||||||
|
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``.
|
||||||
|
|
||||||
|
Minio Server
|
||||||
|
************
|
||||||
|
|
||||||
|
`Minio <https://www.minio.io>`__ is an Open Source Object Storage,
|
||||||
|
written in Go and compatible with AWS S3 API.
|
||||||
|
|
||||||
|
- Download and Install `Minio
|
||||||
|
Server <https://minio.io/downloads/#minio-server>`__.
|
||||||
|
- You can also refer to https://docs.minio.io for step by step guidance
|
||||||
|
on installation and getting started on Minio Client and Minio Server.
|
||||||
|
|
||||||
|
You must first setup the following environment variables with the
|
||||||
|
credentials of your running Minio Server.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export AWS_ACCESS_KEY_ID=<YOUR-MINIO-ACCESS-KEY-ID>
|
||||||
|
$ export AWS_SECRET_ACCESS_KEY= <YOUR-MINIO-SECRET-ACCESS-KEY>
|
||||||
|
|
||||||
|
Now you can easily initialize restic to use Minio server as backend with
|
||||||
|
this command.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ ./restic -r s3:http://localhost:9000/restic init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
created restic backend 6ad29560f5 at s3:http://localhost:9000/restic1
|
||||||
|
Please note that knowledge of your password is required to access
|
||||||
|
the repository. Losing your password means that your data is irrecoverably lost.
|
||||||
|
|
||||||
|
OpenStack Swift
|
||||||
|
***************
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
# For keystone v1 authentication
|
||||||
|
$ export ST_AUTH=<MY_AUTH_URL>
|
||||||
|
$ export ST_USER=<MY_USER_NAME>
|
||||||
|
$ export ST_KEY=<MY_USER_PASSWORD>
|
||||||
|
|
||||||
|
# For keystone v2 authentication (some variables are optional)
|
||||||
|
$ export OS_AUTH_URL=<MY_AUTH_URL>
|
||||||
|
$ export OS_REGION_NAME=<MY_REGION_NAME>
|
||||||
|
$ export OS_USERNAME=<MY_USERNAME>
|
||||||
|
$ export OS_PASSWORD=<MY_PASSWORD>
|
||||||
|
$ export OS_TENANT_ID=<MY_TENANT_ID>
|
||||||
|
$ export OS_TENANT_NAME=<MY_TENANT_NAME>
|
||||||
|
|
||||||
|
# For keystone v3 authentication (some variables are optional)
|
||||||
|
$ export OS_AUTH_URL=<MY_AUTH_URL>
|
||||||
|
$ export OS_REGION_NAME=<MY_REGION_NAME>
|
||||||
|
$ export OS_USERNAME=<MY_USERNAME>
|
||||||
|
$ export OS_PASSWORD=<MY_PASSWORD>
|
||||||
|
$ export OS_USER_DOMAIN_NAME=<MY_DOMAIN_NAME>
|
||||||
|
$ export OS_PROJECT_NAME=<MY_PROJECT_NAME>
|
||||||
|
$ export OS_PROJECT_DOMAIN_NAME=<MY_PROJECT_DOMAIN_NAME>
|
||||||
|
|
||||||
|
# For authentication based on tokens
|
||||||
|
$ export OS_STORAGE_URL=<MY_STORAGE_URL>
|
||||||
|
$ export OS_AUTH_TOKEN=<MY_AUTH_TOKEN>
|
||||||
|
|
||||||
|
|
||||||
|
Restic should be compatible with [OpenStack RC
|
||||||
|
file](https://docs.openstack.org/user-guide/common/cli-set-environment-variables-using-openstack-rc.html)
|
||||||
|
in most cases.
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r swift:container_name:/path init # path is optional
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
created restic backend eefee03bbd at swift:container_name:/path
|
||||||
|
Please note that knowledge of your password is required to access the repository.
|
||||||
|
Losing your password means that your data is irrecoverably lost.
|
||||||
|
|
||||||
|
The policy of new container created by restic can be changed using environment variable:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export SWIFT_DEFAULT_CONTAINER_POLICY=<MY_CONTAINER_POLICY>
|
||||||
|
|
||||||
|
|
||||||
|
Backblaze B2
|
||||||
|
************
|
||||||
|
|
||||||
|
Restic can backup data to any Backblaze B2 bucket. You need to first setup the
|
||||||
|
following environment variables with the credentials you obtained when signed
|
||||||
|
into your B2 account:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export B2_ACCOUNT_ID=<MY_ACCOUNT_ID>
|
||||||
|
$ export B2_ACCOUNT_KEY=<MY_SECRET_ACCOUNT_KEY>
|
||||||
|
|
||||||
|
You can then easily initialize a repository stored at Backblaze B2. If the
|
||||||
|
bucket does not exist yet, it will be created:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r b2:bucketname:path/to/repo init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
created restic backend eefee03bbd at b2:bucketname:path/to/repo
|
||||||
|
Please note that knowledge of your password is required to access the repository.
|
||||||
|
Losing your password means that your data is irrecoverably lost.
|
||||||
|
|
||||||
|
The number of concurrent connections to the B2 service can be set with the `-o
|
||||||
|
b2.connections=10`. By default, at most five parallel connections are
|
||||||
|
established.
|
||||||
|
|
||||||
|
Microsoft Azure Blob Storage
|
||||||
|
****************************
|
||||||
|
|
||||||
|
You can also store backups on Microsoft Azure Blob Storage. Export the Azure
|
||||||
|
account name and key as follows:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export AZURE_ACCOUNT_NAME=<ACCOUNT_NAME>
|
||||||
|
$ export AZURE_ACCOUNT_KEY=<SECRET_KEY>
|
||||||
|
|
||||||
|
Afterwards you can initialize a repository in a container called `foo` in the
|
||||||
|
root path like this:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r azure:foo:/ init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
|
||||||
|
created restic backend a934bac191 at azure:foo:/
|
||||||
|
[...]
|
||||||
|
|
||||||
|
The number of concurrent connections to the B2 service can be set with the
|
||||||
|
`-o azure.connections=10`. By default, at most five parallel connections are
|
||||||
|
established.
|
||||||
|
|
||||||
|
Google Cloud Storage
|
||||||
|
********************
|
||||||
|
|
||||||
|
Restic supports Google Cloud Storage as a backend.
|
||||||
|
|
||||||
|
Restic connects to Google Cloud Storage via a `service account`_.
|
||||||
|
|
||||||
|
For normal restic operation, the service account must have the
|
||||||
|
``storage.objects.{create,delete,get,list}`` permissions for the bucket. These
|
||||||
|
are included in the "Storage Object Admin" role.
|
||||||
|
``restic init`` can create the repository bucket. Doing so requires the
|
||||||
|
``storage.buckets.create`` permission ("Storage Admin" role). If the bucket
|
||||||
|
already exists, that permission is unnecessary.
|
||||||
|
|
||||||
|
To use the Google Cloud Storage backend, first `create a service account key`_
|
||||||
|
and download the JSON credentials file.
|
||||||
|
Second, find 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
|
||||||
|
key file and the project ID as follows:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export GOOGLE_PROJECT_ID=123123123123
|
||||||
|
$ export GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gs-secret-restic-key.json
|
||||||
|
|
||||||
|
Then you can use the ``gs:`` backend type to create a new repository in the
|
||||||
|
bucket `foo` at the root path:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r gs:foo:/ init
|
||||||
|
enter password for new backend:
|
||||||
|
enter password again:
|
||||||
|
|
||||||
|
created restic backend bde47d6254 at gs:foo2/
|
||||||
|
[...]
|
||||||
|
|
||||||
|
The number of concurrent connections to the GCS service can be set with the
|
||||||
|
`-o gs.connections=10`. By default, at most five parallel connections are
|
||||||
|
established.
|
||||||
|
|
||||||
|
.. _service account: https://cloud.google.com/storage/docs/authentication#service_accounts
|
||||||
|
.. _create a service account key: https://cloud.google.com/storage/docs/authentication#generating-a-private-key
|
||||||
|
|
||||||
|
Password prompt on Windows
|
||||||
|
**************************
|
||||||
|
|
||||||
|
At the moment, restic only supports the default Windows console
|
||||||
|
interaction. If you use emulation environments like
|
||||||
|
`MSYS2 <https://msys2.github.io/>`__ or
|
||||||
|
`Cygwin <https://www.cygwin.com/>`__, 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 <https://sourceforge.net/p/msys2/wiki/Porting/>`__ and
|
||||||
|
`here <https://github.com/rprichard/winpty>`__ for detail information).
|
||||||
|
On MSYS2, you can install ``winpty`` as follows:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ pacman -S winpty
|
||||||
|
$ winpty restic -r /tmp/backup init
|
||||||
|
|
180
doc/040_backup.rst
Normal file
180
doc/040_backup.rst
Normal file
|
@ -0,0 +1,180 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
##########
|
||||||
|
Backing up
|
||||||
|
##########
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /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
|
||||||
|
|
||||||
|
As you can see, restic created a backup of the directory and was pretty
|
||||||
|
fast! The specific snapshot just created is identified by a sequence of
|
||||||
|
hexadecimal characters, ``40dc1520`` in this case.
|
||||||
|
|
||||||
|
If you run the command again, restic will create another snapshot of
|
||||||
|
your data, but this time it's even faster. This is de-duplication at
|
||||||
|
work!
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup backup ~/work
|
||||||
|
enter password for repository:
|
||||||
|
using parent snapshot 40dc1520aa6a07b7b3ae561786770a01951245d2367241e71e9485f18ae8228c
|
||||||
|
scan [/home/user/work]
|
||||||
|
scanned 764 directories, 1816 files in 0:00
|
||||||
|
[0:00] 100.00% 0B/s 1.582 GiB / 1.582 GiB 2580 / 2580 items 0 errors ETA 0:00
|
||||||
|
duration: 0:00, 6572.38MiB/s
|
||||||
|
snapshot 79766175 saved
|
||||||
|
|
||||||
|
You can even backup individual files in the same repository.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup backup ~/work.txt
|
||||||
|
scan [/home/user/work.txt]
|
||||||
|
scanned 0 directories, 1 files in 0:00
|
||||||
|
[0:00] 100.00% 0B/s 220B / 220B 1 / 1 items 0 errors ETA 0:00
|
||||||
|
duration: 0:00, 0.03MiB/s
|
||||||
|
snapshot 31f7bd63 saved
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Now is a good time to run ``restic check`` to verify that all data
|
||||||
|
is properly stored in the repository. You should run this command regularly
|
||||||
|
to make sure the internal structure of the repository is free of errors.
|
||||||
|
|
||||||
|
You can exclude folders and files by specifying exclude-patterns. Either
|
||||||
|
specify them with multiple ``--exclude``'s or one ``--exclude-file``
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ cat exclude
|
||||||
|
# exclude go-files
|
||||||
|
*.go
|
||||||
|
# exclude foo/x/y/z/bar foo/x/bar foo/bar
|
||||||
|
foo/**/bar
|
||||||
|
$ restic -r /tmp/backup backup ~/work --exclude=*.c --exclude-file=exclude
|
||||||
|
|
||||||
|
Patterns use `filepath.Glob <https://golang.org/pkg/path/filepath/#Glob>`__ internally,
|
||||||
|
see `filepath.Match <https://golang.org/pkg/path/filepath/#Match>`__ for syntax.
|
||||||
|
Additionally ``**`` excludes arbitrary subdirectories.
|
||||||
|
Environment-variables in exclude-files are expanded with
|
||||||
|
`os.ExpandEnv <https://golang.org/pkg/os/#ExpandEnv>`__.
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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.
|
||||||
|
|
||||||
|
or example maybe you want to backup files that have a certain filename
|
||||||
|
in them:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ find /tmp/somefiles | grep 'PATTERN' > /tmp/files_to_backup
|
||||||
|
|
||||||
|
You can then use restic to backup the filtered files:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup backup --files-from /tmp/files_to_backup
|
||||||
|
|
||||||
|
Incidentally you can also combine ``--files-from`` with the normal files
|
||||||
|
args:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup backup --files-from /tmp/files_to_backup /tmp/some_additional_file
|
||||||
|
|
||||||
|
Backing up special items
|
||||||
|
************************
|
||||||
|
|
||||||
|
**Symlinks** are archieved as symlinks, ``restic`` does not follow them.
|
||||||
|
When you restore, you get the same symlink again, with the same link target
|
||||||
|
and the same timestamps.
|
||||||
|
|
||||||
|
If there is a **bind-mount** below a directory that is to be saved, restic descends into it.
|
||||||
|
|
||||||
|
**Device files** are saved and restored as device files. This means that e.g. ``/dev/sda`` is
|
||||||
|
archived as a block device file and restored as such. This also means that the content of the
|
||||||
|
corresponding disk is not read, at least not from the device file.
|
||||||
|
|
||||||
|
|
||||||
|
Reading data from stdin
|
||||||
|
***********************
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ mysqldump [...] | restic -r /tmp/backup backup --stdin --stdin-filename production.sql
|
||||||
|
|
||||||
|
Tags for backup
|
||||||
|
***************
|
||||||
|
|
||||||
|
Snapshots can have one or more tags, short strings which add identifying
|
||||||
|
information. Just specify the tags for a snapshot one by one with ``--tag``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup backup --tag projectX --tag foo --tag bar ~/work
|
||||||
|
[...]
|
||||||
|
|
||||||
|
The tags can later be used to keep (or forget) snapshots with the ``forget``
|
||||||
|
command. The command ``tag`` can be used to modify tags on an existing
|
||||||
|
snapshot.
|
89
doc/045_working_with_repos.rst
Normal file
89
doc/045_working_with_repos.rst
Normal file
|
@ -0,0 +1,89 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
|
||||||
|
#########################
|
||||||
|
Working with repositories
|
||||||
|
#########################
|
||||||
|
|
||||||
|
Listing all snapshots
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Now, you can list all the snapshots stored in the repository:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots
|
||||||
|
enter password for repository:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
40dc1520 2015-05-08 21:38:30 kasimir /home/user/work
|
||||||
|
79766175 2015-05-08 21:40:19 kasimir /home/user/work
|
||||||
|
bdbd3439 2015-05-08 21:45:17 luigi /home/art
|
||||||
|
590c8fc8 2015-05-08 21:47:38 kazik /srv
|
||||||
|
9f0bc19e 2015-05-08 21:46:11 luigi /srv
|
||||||
|
|
||||||
|
You can filter the listing by directory path:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots --path="/srv"
|
||||||
|
enter password for repository:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
590c8fc8 2015-05-08 21:47:38 kazik /srv
|
||||||
|
9f0bc19e 2015-05-08 21:46:11 luigi /srv
|
||||||
|
|
||||||
|
Or filter by host:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots --host luigi
|
||||||
|
enter password for repository:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
bdbd3439 2015-05-08 21:45:17 luigi /home/art
|
||||||
|
9f0bc19e 2015-05-08 21:46:11 luigi /srv
|
||||||
|
|
||||||
|
Combining filters is also possible.
|
||||||
|
|
||||||
|
|
||||||
|
Checking a repo's integrity and consistency
|
||||||
|
===========================================
|
||||||
|
|
||||||
|
Imagine your repository is saved on a server that has a faulty hard
|
||||||
|
drive, or even worse, attackers get privileged access and modify your
|
||||||
|
backup with the intention to make you restore malicious data:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ sudo echo "boom" >> backup/index/d795ffa99a8ab8f8e42cec1f814df4e48b8f49129360fb57613df93739faee97
|
||||||
|
|
||||||
|
In order to detect these things, it is a good idea to regularly use the
|
||||||
|
``check`` command to test whether everything is alright, your precious
|
||||||
|
backup data is consistent and the integrity is unharmed:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup check
|
||||||
|
Load indexes
|
||||||
|
ciphertext verification failed
|
||||||
|
|
||||||
|
Trying to restore a snapshot which has been modified as shown above will
|
||||||
|
yield the same error:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup restore 79766175 --target /tmp/restore-work
|
||||||
|
Load indexes
|
||||||
|
ciphertext verification failed
|
||||||
|
|
73
doc/050_restore.rst
Normal file
73
doc/050_restore.rst
Normal file
|
@ -0,0 +1,73 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
#####################
|
||||||
|
Restoring from backup
|
||||||
|
#####################
|
||||||
|
|
||||||
|
Restoring from a snapshot
|
||||||
|
=========================
|
||||||
|
|
||||||
|
Restoring a snapshot is as easy as it sounds, just use the following
|
||||||
|
command to restore the contents of the latest snapshot to
|
||||||
|
``/tmp/restore-work``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup restore 79766175 --target /tmp/restore-work
|
||||||
|
enter password for repository:
|
||||||
|
restoring <Snapshot of [/home/user/work] at 2015-05-08 21:40:19.884408621 +0200 CEST> to /tmp/restore-work
|
||||||
|
|
||||||
|
Use the word ``latest`` to restore the last backup. You can also combine
|
||||||
|
``latest`` with the ``--host`` and ``--path`` filters to choose the last
|
||||||
|
backup for a specific host, path or both.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup restore latest --target /tmp/restore-art --path "/home/art" --host luigi
|
||||||
|
enter password for repository:
|
||||||
|
restoring <Snapshot of [/home/art] at 2015-05-08 21:45:17.884408621 +0200 CEST> to /tmp/restore-art
|
||||||
|
|
||||||
|
Use ``--exclude`` and ``--include`` to restrict the restore to a subset of
|
||||||
|
files in the snapshot. For example, to restore a single file:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup restore 79766175 --target /tmp/restore-work --include /work/foo
|
||||||
|
enter password for repository:
|
||||||
|
restoring <Snapshot of [/home/user/work] at 2015-05-08 21:40:19.884408621 +0200 CEST> to /tmp/restore-work
|
||||||
|
|
||||||
|
This will restore the file ``foo`` to ``/tmp/restore-work/work/foo``.
|
||||||
|
|
||||||
|
Restore using mount
|
||||||
|
===================
|
||||||
|
|
||||||
|
Browsing your backup as a regular file system is also very easy. First,
|
||||||
|
create a mount point such as ``/mnt/restic`` and then use the following
|
||||||
|
command to serve the repository with FUSE:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ mkdir /mnt/restic
|
||||||
|
$ restic -r /tmp/backup mount /mnt/restic
|
||||||
|
enter password for repository:
|
||||||
|
Now serving /tmp/backup at /mnt/restic
|
||||||
|
Don't forget to umount after quitting!
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
208
doc/060_forget.rst
Normal file
208
doc/060_forget.rst
Normal file
|
@ -0,0 +1,208 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
#########################
|
||||||
|
Removing backup snapshots
|
||||||
|
#########################
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
It is advisable to run ``restic check`` after pruning, to make sure
|
||||||
|
you are alerted, should the internal data structures of the repository
|
||||||
|
be damaged.
|
||||||
|
|
||||||
|
Remove a single snapshot
|
||||||
|
************************
|
||||||
|
|
||||||
|
The command ``snapshots`` can be used to list all snapshots in a
|
||||||
|
repository like this:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots
|
||||||
|
enter password for repository:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
40dc1520 2015-05-08 21:38:30 kasimir /home/user/work
|
||||||
|
79766175 2015-05-08 21:40:19 kasimir /home/user/work
|
||||||
|
bdbd3439 2015-05-08 21:45:17 luigi /home/art
|
||||||
|
590c8fc8 2015-05-08 21:47:38 kazik /srv
|
||||||
|
9f0bc19e 2015-05-08 21:46:11 luigi /srv
|
||||||
|
|
||||||
|
In order to remove the snapshot of ``/home/art``, use the ``forget``
|
||||||
|
command and specify the snapshot ID on the command line:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup forget bdbd3439
|
||||||
|
enter password for repository:
|
||||||
|
removed snapshot d3f01f63
|
||||||
|
|
||||||
|
Afterwards this snapshot is removed:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots
|
||||||
|
enter password for repository:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
40dc1520 2015-05-08 21:38:30 kasimir /home/user/work
|
||||||
|
79766175 2015-05-08 21:40:19 kasimir /home/user/work
|
||||||
|
590c8fc8 2015-05-08 21:47:38 kazik /srv
|
||||||
|
9f0bc19e 2015-05-08 21:46:11 luigi /srv
|
||||||
|
|
||||||
|
But the data that was referenced by files in this snapshot is still
|
||||||
|
stored in the repository. To cleanup unreferenced data, the ``prune``
|
||||||
|
command must be run:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup prune
|
||||||
|
enter password for repository:
|
||||||
|
|
||||||
|
counting files in repo
|
||||||
|
building new index for repo
|
||||||
|
[0:00] 100.00% 22 / 22 files
|
||||||
|
repository contains 22 packs (8512 blobs) with 100.092 MiB bytes
|
||||||
|
processed 8512 blobs: 0 duplicate blobs, 0B duplicate
|
||||||
|
load all snapshots
|
||||||
|
find data that is still in use for 1 snapshots
|
||||||
|
[0:00] 100.00% 1 / 1 snapshots
|
||||||
|
found 8433 of 8512 data blobs still in use
|
||||||
|
will rewrite 3 packs
|
||||||
|
creating new index
|
||||||
|
[0:00] 86.36% 19 / 22 files
|
||||||
|
saved new index as 544a5084
|
||||||
|
done
|
||||||
|
|
||||||
|
Afterwards the repository is smaller.
|
||||||
|
|
||||||
|
You can automate this two-step process by using the ``--prune`` switch
|
||||||
|
to ``forget``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic forget --keep-last 1 --prune
|
||||||
|
snapshots for host mopped, directories /home/user/work:
|
||||||
|
|
||||||
|
keep 1 snapshots:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
4bba301e 2017-02-21 10:49:18 mopped /home/user/work
|
||||||
|
|
||||||
|
remove 1 snapshots:
|
||||||
|
ID Date Host Tags Directory
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
8c02b94b 2017-02-21 10:48:33 mopped /home/user/work
|
||||||
|
|
||||||
|
1 snapshots have been removed, running prune
|
||||||
|
counting files in repo
|
||||||
|
building new index for repo
|
||||||
|
[0:00] 100.00% 37 / 37 packs
|
||||||
|
repository contains 37 packs (5521 blobs) with 151.012 MiB bytes
|
||||||
|
processed 5521 blobs: 0 duplicate blobs, 0B duplicate
|
||||||
|
load all snapshots
|
||||||
|
find data that is still in use for 1 snapshots
|
||||||
|
[0:00] 100.00% 1 / 1 snapshots
|
||||||
|
found 5323 of 5521 data blobs still in use, removing 198 blobs
|
||||||
|
will delete 0 packs and rewrite 27 packs, this frees 22.106 MiB
|
||||||
|
creating new index
|
||||||
|
[0:00] 100.00% 30 / 30 packs
|
||||||
|
saved new index as b49f3e68
|
||||||
|
done
|
||||||
|
|
||||||
|
Removing snapshots according to a policy
|
||||||
|
****************************************
|
||||||
|
|
||||||
|
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-by paths,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-last n`` never delete the ``n`` last (most recent) snapshots
|
||||||
|
- ``--keep-hourly n`` for the last ``n`` hours in which a snapshot was
|
||||||
|
made, keep only the last snapshot for each hour.
|
||||||
|
- ``--keep-daily n`` for the last ``n`` days which have one or more
|
||||||
|
snapshots, only keep the last one for that day.
|
||||||
|
- ``--keep-weekly n`` for the last ``n`` weeks which have one or more
|
||||||
|
snapshots, only keep the last one for that week.
|
||||||
|
- ``--keep-monthly n`` for the last ``n`` months which have one or more
|
||||||
|
snapshots, only keep the last one for that month.
|
||||||
|
- ``--keep-yearly n`` 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``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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-daily 4`` 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-daily 4`` on a Friday would remove all snapshots!
|
||||||
|
|
||||||
|
Another example: Suppose you make daily backups for 100 years. Then
|
||||||
|
``forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 75``
|
||||||
|
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.
|
||||||
|
|
51
doc/070_encryption.rst
Normal file
51
doc/070_encryption.rst
Normal file
|
@ -0,0 +1,51 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
##########
|
||||||
|
Encryption
|
||||||
|
##########
|
||||||
|
|
||||||
|
|
||||||
|
*"The design might not be perfect, but it’s good. Encryption is a first-class feature,
|
||||||
|
the implementation looks sane and I guess the deduplication trade-off is worth it. So… I’m going to use restic for
|
||||||
|
my personal backups.*" `Filippo Valsorda`_
|
||||||
|
|
||||||
|
.. _Filippo Valsorda: https://blog.filippo.io/restic-cryptography/
|
||||||
|
|
||||||
|
**********************
|
||||||
|
Manage repository keys
|
||||||
|
**********************
|
||||||
|
|
||||||
|
The ``key`` command allows you to set multiple access keys or passwords
|
||||||
|
per repository. In fact, you can use the ``list``, ``add``, ``remove``
|
||||||
|
and ``passwd`` sub-commands to manage these keys very precisely:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup key list
|
||||||
|
enter password for repository:
|
||||||
|
ID User Host Created
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
*eb78040b username kasimir 2015-08-12 13:29:57
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup key add
|
||||||
|
enter password for repository:
|
||||||
|
enter password for new key:
|
||||||
|
enter password again:
|
||||||
|
saved new key as <Key of username@kasimir, created on 2015-08-12 13:35:05.316831933 +0200 CEST>
|
||||||
|
|
||||||
|
$ restic -r backup key list
|
||||||
|
enter password for repository:
|
||||||
|
ID User Host Created
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
5c657874 username kasimir 2015-08-12 13:35:05
|
||||||
|
*eb78040b username kasimir 2015-08-12 13:29:57
|
|
@ -1,15 +1,32 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
########
|
||||||
|
Examples
|
||||||
|
########
|
||||||
|
|
||||||
|
********************************
|
||||||
Setting up restic with Amazon S3
|
Setting up restic with Amazon S3
|
||||||
================================
|
********************************
|
||||||
|
|
||||||
Preface
|
Preface
|
||||||
-------
|
=======
|
||||||
|
|
||||||
This tutorial will show you how to use restic with AWS S3. It will show you how
|
This tutorial will show you how to use restic with AWS S3. It will show you how
|
||||||
to navigate the AWS web interface, create an S3 bucket, create a user with
|
to navigate the AWS web interface, create an S3 bucket, create a user with
|
||||||
access to only this bucket, and finally how to connect restic to this bucket.
|
access to only this bucket, and finally how to connect restic to this bucket.
|
||||||
|
|
||||||
Prerequisites
|
Prerequisites
|
||||||
-------------
|
=============
|
||||||
|
|
||||||
You should already have a ``restic`` binary available on your system that you can
|
You should already have a ``restic`` binary available on your system that you can
|
||||||
run. Furthermore, you should also have an account with
|
run. Furthermore, you should also have an account with
|
||||||
|
@ -19,7 +36,7 @@ details for billing purposes, even if you use their
|
||||||
|
|
||||||
|
|
||||||
Logging into AWS
|
Logging into AWS
|
||||||
----------------
|
================
|
||||||
|
|
||||||
Point your browser to
|
Point your browser to
|
||||||
https://console.aws.amazon.com
|
https://console.aws.amazon.com
|
||||||
|
@ -39,7 +56,7 @@ Access Management (IAM) are relevant.
|
||||||
|
|
||||||
|
|
||||||
Creating the bucket
|
Creating the bucket
|
||||||
-------------------
|
===================
|
||||||
|
|
||||||
First, a bucket to store your backups in must be created. Using the "Services"
|
First, a bucket to store your backups in must be created. Using the "Services"
|
||||||
menu, navigate to S3. In case you already have some S3 buckets, you will see a
|
menu, navigate to S3. In case you already have some S3 buckets, you will see a
|
||||||
|
@ -71,7 +88,7 @@ buckets:
|
||||||
:alt: List With New Bucket
|
:alt: List With New Bucket
|
||||||
|
|
||||||
Creating a user
|
Creating a user
|
||||||
---------------
|
===============
|
||||||
|
|
||||||
Use the "Services" menu of the AWS web interface to navigate to IAM. This will
|
Use the "Services" menu of the AWS web interface to navigate to IAM. This will
|
||||||
bring you to the IAM homepage. To create a new user, click on the "Users" menu
|
bring you to the IAM homepage. To create a new user, click on the "Users" menu
|
||||||
|
@ -177,7 +194,7 @@ browser now.
|
||||||
|
|
||||||
|
|
||||||
Initializing the restic repository
|
Initializing the restic repository
|
||||||
----------------------------------
|
==================================
|
||||||
|
|
||||||
Open a terminal and make sure you have the ``restic`` binary ready. First, choose
|
Open a terminal and make sure you have the ``restic`` binary ready. First, choose
|
||||||
a password to encrypt your backups with. In this tutorial, ``apg`` is used for
|
a password to encrypt your backups with. In this tutorial, ``apg`` is used for
|
|
@ -1,8 +1,75 @@
|
||||||
Development
|
..
|
||||||
===========
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
#############
|
||||||
|
Participating
|
||||||
|
#############
|
||||||
|
|
||||||
|
*********
|
||||||
|
Debugging
|
||||||
|
*********
|
||||||
|
|
||||||
|
The program can be built with debug support like this:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ go run build.go -tags debug
|
||||||
|
|
||||||
|
Afterwards, extensive debug messages are written to the file in
|
||||||
|
environment variable ``DEBUG_LOG``, e.g.:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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 <https://golang.org/pkg/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 ``*``:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ 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):
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ DEBUG_FUNCS=*unlock* restic check
|
||||||
|
|
||||||
|
|
||||||
|
************
|
||||||
|
Contributing
|
||||||
|
************
|
||||||
|
|
||||||
Contribute
|
|
||||||
----------
|
|
||||||
Contributions are welcome! Please **open an issue first** (or add a
|
Contributions are welcome! Please **open an issue first** (or add a
|
||||||
comment to an existing issue) if you plan to work on any code or add a
|
comment to an existing issue) if you plan to work on any code or add a
|
||||||
new feature. This way, duplicate work is prevented and we can discuss
|
new feature. This way, duplicate work is prevented and we can discuss
|
||||||
|
@ -21,8 +88,10 @@ A few issues have been tagged with the label ``help wanted``, you can
|
||||||
start looking at those:
|
start looking at those:
|
||||||
https://github.com/restic/restic/labels/help%20wanted
|
https://github.com/restic/restic/labels/help%20wanted
|
||||||
|
|
||||||
|
********
|
||||||
Security
|
Security
|
||||||
--------
|
********
|
||||||
|
|
||||||
**Important**: If you discover something that you believe to be a
|
**Important**: If you discover something that you believe to be a
|
||||||
possible critical security problem, please do *not* open a GitHub issue
|
possible critical security problem, please do *not* open a GitHub issue
|
||||||
but send an email directly to alexander@bumpern.de. If possible, please
|
but send an email directly to alexander@bumpern.de. If possible, please
|
||||||
|
@ -36,8 +105,9 @@ encrypt your email using the following PGP key
|
||||||
uid Alexander Neumann <alexander@bumpern.de>
|
uid Alexander Neumann <alexander@bumpern.de>
|
||||||
sub 4096R/D5FC2ACF4043FDF1 2014-11-01
|
sub 4096R/D5FC2ACF4043FDF1 2014-11-01
|
||||||
|
|
||||||
|
*************
|
||||||
Compatibility
|
Compatibility
|
||||||
-------------
|
*************
|
||||||
|
|
||||||
Backward compatibility for backups is important so that our users are
|
Backward compatibility for backups is important so that our users are
|
||||||
always able to restore saved data. Therefore restic follows `Semantic
|
always able to restore saved data. Therefore restic follows `Semantic
|
||||||
|
@ -52,8 +122,9 @@ version; as long as we do not increment the major version, data can be
|
||||||
read and restored. We strive to be fully backward compatible to all
|
read and restored. We strive to be fully backward compatible to all
|
||||||
prior versions.
|
prior versions.
|
||||||
|
|
||||||
|
**********************
|
||||||
Building documentation
|
Building documentation
|
||||||
----------------------
|
**********************
|
||||||
|
|
||||||
The restic documentation is built with `Sphinx <http://sphinx-doc.org>`__,
|
The restic documentation is built with `Sphinx <http://sphinx-doc.org>`__,
|
||||||
therefore building it locally requires a recent Python version and requirements listed in ``doc/requirements.txt``.
|
therefore building it locally requires a recent Python version and requirements listed in ``doc/requirements.txt``.
|
|
@ -1,8 +1,25 @@
|
||||||
|
..
|
||||||
|
Normally, there are no heading levels assigned to certain characters as the structure is
|
||||||
|
determined from the succession of headings. However, this convention is used in Python’s
|
||||||
|
Style Guide for documenting which you may follow:
|
||||||
|
|
||||||
|
# with overline, for parts
|
||||||
|
* for chapters
|
||||||
|
= for sections
|
||||||
|
- for subsections
|
||||||
|
^ for subsubsections
|
||||||
|
" for paragraphs
|
||||||
|
|
||||||
|
##########
|
||||||
|
References
|
||||||
|
##########
|
||||||
|
|
||||||
|
******
|
||||||
Design
|
Design
|
||||||
======
|
******
|
||||||
|
|
||||||
Terminology
|
Terminology
|
||||||
-----------
|
===========
|
||||||
|
|
||||||
This section introduces terminology used in this document.
|
This section introduces terminology used in this document.
|
||||||
|
|
||||||
|
@ -26,7 +43,7 @@ the repository. This ID is required in order to load the file from the
|
||||||
repository.
|
repository.
|
||||||
|
|
||||||
Repository Format
|
Repository Format
|
||||||
-----------------
|
=================
|
||||||
|
|
||||||
All data is stored in a restic repository. A repository is able to store
|
All data is stored in a restic repository. A repository is able to store
|
||||||
data of several different types, which can later be requested based on
|
data of several different types, which can later be requested based on
|
||||||
|
@ -77,7 +94,7 @@ locally. The field ``chunker_polynomial`` contains a parameter that is
|
||||||
used for splitting large files into smaller chunks (see below).
|
used for splitting large files into smaller chunks (see below).
|
||||||
|
|
||||||
Repository Layout
|
Repository Layout
|
||||||
~~~~~~~~~~~~~~~~~
|
-----------------
|
||||||
|
|
||||||
The ``local`` and ``sftp`` backends are implemented using files and
|
The ``local`` and ``sftp`` backends are implemented using files and
|
||||||
directories stored in a file system. The directory layout is the same
|
directories stored in a file system. The directory layout is the same
|
||||||
|
@ -125,7 +142,7 @@ the option ``-o local.layout=default``, valid values are ``default`` and
|
||||||
s3 backend ``s3.layout``.
|
s3 backend ``s3.layout``.
|
||||||
|
|
||||||
S3 Legacy Layout
|
S3 Legacy Layout
|
||||||
~~~~~~~~~~~~~~~~
|
----------------
|
||||||
|
|
||||||
Unfortunately during development the AWS S3 backend uses slightly different
|
Unfortunately during development the AWS S3 backend uses slightly different
|
||||||
paths (directory names use singular instead of plural for ``key``,
|
paths (directory names use singular instead of plural for ``key``,
|
||||||
|
@ -154,7 +171,7 @@ The S3 backend understands and accepts both forms, new backends are
|
||||||
always created with the default layout for compatibility reasons.
|
always created with the default layout for compatibility reasons.
|
||||||
|
|
||||||
Pack Format
|
Pack Format
|
||||||
-----------
|
===========
|
||||||
|
|
||||||
All files in the repository except Key and Pack files just contain raw
|
All files in the repository except Key and Pack files just contain raw
|
||||||
data, stored as ``IV || Ciphertext || MAC``. Pack files may contain one
|
data, stored as ``IV || Ciphertext || MAC``. Pack files may contain one
|
||||||
|
@ -212,7 +229,7 @@ header. Afterwards, the header can be read and parsed, which yields all
|
||||||
plaintext hashes, types, offsets and lengths of all included blobs.
|
plaintext hashes, types, offsets and lengths of all included blobs.
|
||||||
|
|
||||||
Indexing
|
Indexing
|
||||||
--------
|
========
|
||||||
|
|
||||||
Index files contain information about Data and Tree Blobs and the Packs
|
Index files contain information about Data and Tree Blobs and the Packs
|
||||||
they are contained in and store this information in the repository. When
|
they are contained in and store this information in the repository. When
|
||||||
|
@ -268,7 +285,7 @@ on non-disjoint sets of Packs. The number of packs described in a single
|
||||||
file is chosen so that the file size is kept below 8 MiB.
|
file is chosen so that the file size is kept below 8 MiB.
|
||||||
|
|
||||||
Keys, Encryption and MAC
|
Keys, Encryption and MAC
|
||||||
------------------------
|
========================
|
||||||
|
|
||||||
All data stored by restic in the repository is encrypted with AES-256 in
|
All data stored by restic in the repository is encrypted with AES-256 in
|
||||||
counter mode and authenticated using Poly1305-AES. For encrypting new
|
counter mode and authenticated using Poly1305-AES. For encrypting new
|
||||||
|
@ -347,7 +364,7 @@ each. This way, the password can be changed without having to re-encrypt
|
||||||
all data.
|
all data.
|
||||||
|
|
||||||
Snapshots
|
Snapshots
|
||||||
---------
|
=========
|
||||||
|
|
||||||
A snapshot represents a directory with all files and sub-directories at
|
A snapshot represents a directory with all files and sub-directories at
|
||||||
a given point in time. For each backup that is made, a new snapshot is
|
a given point in time. For each backup that is made, a new snapshot is
|
||||||
|
@ -417,7 +434,7 @@ a Pack file , an index is used. If the index is not available, the
|
||||||
header of all data Blobs can be read.
|
header of all data Blobs can be read.
|
||||||
|
|
||||||
Trees and Data
|
Trees and Data
|
||||||
--------------
|
==============
|
||||||
|
|
||||||
A snapshot references a tree by the SHA-256 hash of the JSON string
|
A snapshot references a tree by the SHA-256 hash of the JSON string
|
||||||
representation of its contents. Trees and data are saved in pack files
|
representation of its contents. Trees and data are saved in pack files
|
||||||
|
@ -503,7 +520,7 @@ matches the plaintext hash from the map included in the tree above, so
|
||||||
the correct data has been returned.
|
the correct data has been returned.
|
||||||
|
|
||||||
Locks
|
Locks
|
||||||
-----
|
=====
|
||||||
|
|
||||||
The restic repository structure is designed in a way that allows
|
The restic repository structure is designed in a way that allows
|
||||||
parallel access of multiple instance of restic and even parallel writes.
|
parallel access of multiple instance of restic and even parallel writes.
|
||||||
|
@ -547,7 +564,7 @@ appeared in the repository. Depending on the type of the other locks and
|
||||||
the lock to be created, restic either continues or fails.
|
the lock to be created, restic either continues or fails.
|
||||||
|
|
||||||
Backups and Deduplication
|
Backups and Deduplication
|
||||||
-------------------------
|
=========================
|
||||||
|
|
||||||
For creating a backup, restic scans the source directory for all files,
|
For creating a backup, restic scans the source directory for all files,
|
||||||
sub-directories and other entries. The data from each file is split into
|
sub-directories and other entries. The data from each file is split into
|
||||||
|
@ -565,7 +582,7 @@ backup. This even works if bytes are inserted or removed at arbitrary
|
||||||
positions within the file.
|
positions within the file.
|
||||||
|
|
||||||
Threat Model
|
Threat Model
|
||||||
------------
|
============
|
||||||
|
|
||||||
The design goals for restic include being able to securely store backups
|
The design goals for restic include being able to securely store backups
|
||||||
in a location that is not completely trusted, e.g. a shared system where
|
in a location that is not completely trusted, e.g. a shared system where
|
||||||
|
@ -607,3 +624,140 @@ stored files) which files belong to what snapshot. When only these files
|
||||||
are deleted, the particular snapshot vanished and all snapshots
|
are deleted, the particular snapshot vanished and all snapshots
|
||||||
depending on data that has been added in the snapshot cannot be restored
|
depending on data that has been added in the snapshot cannot be restored
|
||||||
completely. Restic is not designed to detect this attack.
|
completely. Restic is not designed to detect this attack.
|
||||||
|
|
||||||
|
Local Cache
|
||||||
|
===========
|
||||||
|
|
||||||
|
In order to speed up certain operations, restic manages a local cache of data.
|
||||||
|
This document describes the data structures for the local cache with version 1.
|
||||||
|
|
||||||
|
Versions
|
||||||
|
--------
|
||||||
|
|
||||||
|
The cache directory is selected according to the `XDG base dir specification
|
||||||
|
<http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html>`__.
|
||||||
|
Each repository has its own cache sub-directory, consting of the repository ID
|
||||||
|
which is chosen at ``init``. All cache directories for different repos are
|
||||||
|
independent of each other.
|
||||||
|
|
||||||
|
The cache dir for a repo contains a file named ``version``, which contains a
|
||||||
|
single ASCII integer line that stands for the current version of the cache. If
|
||||||
|
a lower version number is found the cache is recreated with the current
|
||||||
|
version. If a higher version number is found the cache is ignored and left as
|
||||||
|
is.
|
||||||
|
|
||||||
|
Snapshots and Indexes
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Snapshot, Data and Index files are cached in the sub-directories ``snapshots``,
|
||||||
|
``data`` and ``index``, as read from the repository.
|
||||||
|
|
||||||
|
|
||||||
|
************
|
||||||
|
REST Backend
|
||||||
|
************
|
||||||
|
|
||||||
|
Restic can interact with HTTP Backend that respects the following REST
|
||||||
|
API. The following values are valid for ``{type}``: ``data``, ``keys``,
|
||||||
|
``locks``, ``snapshots``, ``index``, ``config``. ``{path}`` is a path to
|
||||||
|
the repository, so that multiple different repositories can be accessed.
|
||||||
|
The default path is ``/``.
|
||||||
|
|
||||||
|
POST {path}?create=true
|
||||||
|
=======================
|
||||||
|
|
||||||
|
This request is used to initially create a new repository. The server
|
||||||
|
responds with "200 OK" if the repository structure was created
|
||||||
|
successfully or already exists, otherwise an error is returned.
|
||||||
|
|
||||||
|
DELETE {path}
|
||||||
|
=============
|
||||||
|
|
||||||
|
Deletes the repository on the server side. The server responds with "200
|
||||||
|
OK" if the repository was successfully removed. If this function is not
|
||||||
|
implemented the server returns "501 Not Implemented", if this it is
|
||||||
|
denied by the server it returns "403 Forbidden".
|
||||||
|
|
||||||
|
HEAD {path}/config
|
||||||
|
==================
|
||||||
|
|
||||||
|
Returns "200 OK" if the repository has a configuration, an HTTP error
|
||||||
|
otherwise.
|
||||||
|
|
||||||
|
GET {path}/config
|
||||||
|
=================
|
||||||
|
|
||||||
|
Returns the content of the configuration file if the repository has a
|
||||||
|
configuration, an HTTP error otherwise.
|
||||||
|
|
||||||
|
Response format: binary/octet-stream
|
||||||
|
|
||||||
|
POST {path}/config
|
||||||
|
==================
|
||||||
|
|
||||||
|
Returns "200 OK" if the configuration of the request body has been
|
||||||
|
saved, an HTTP error otherwise.
|
||||||
|
|
||||||
|
GET {path}/{type}/
|
||||||
|
==================
|
||||||
|
|
||||||
|
Returns a JSON array containing the names of all the blobs stored for a
|
||||||
|
given type.
|
||||||
|
|
||||||
|
Response format: JSON
|
||||||
|
|
||||||
|
HEAD {path}/{type}/{name}
|
||||||
|
=========================
|
||||||
|
|
||||||
|
Returns "200 OK" if the blob with the given name and type is stored in
|
||||||
|
the repository, "404 not found" otherwise. If the blob exists, the HTTP
|
||||||
|
header ``Content-Length`` is set to the file size.
|
||||||
|
|
||||||
|
GET {path}/{type}/{name}
|
||||||
|
========================
|
||||||
|
|
||||||
|
Returns the content of the blob with the given name and type if it is
|
||||||
|
stored in the repository, "404 not found" otherwise.
|
||||||
|
|
||||||
|
If the request specifies a partial read with a Range header field, then
|
||||||
|
the status code of the response is 206 instead of 200 and the response
|
||||||
|
only contains the specified range.
|
||||||
|
|
||||||
|
Response format: binary/octet-stream
|
||||||
|
|
||||||
|
POST {path}/{type}/{name}
|
||||||
|
=========================
|
||||||
|
|
||||||
|
Saves the content of the request body as a blob with the given name and
|
||||||
|
type, an HTTP error otherwise.
|
||||||
|
|
||||||
|
Request format: binary/octet-stream
|
||||||
|
|
||||||
|
DELETE {path}/{type}/{name}
|
||||||
|
===========================
|
||||||
|
|
||||||
|
Returns "200 OK" if the blob with the given name and type has been
|
||||||
|
deleted from the repository, an HTTP error otherwise.
|
||||||
|
|
||||||
|
|
||||||
|
*****
|
||||||
|
Talks
|
||||||
|
*****
|
||||||
|
|
||||||
|
The following talks will be or have been given about restic:
|
||||||
|
|
||||||
|
- 2016-01-31: Lightning Talk at the Go Devroom at FOSDEM 2016,
|
||||||
|
Brussels, Belgium
|
||||||
|
- 2016-01-29: `restic - Backups mal
|
||||||
|
richtig <https://media.ccc.de/v/c4.openchaos.2016.01.restic>`__:
|
||||||
|
Public lecture in German at `CCC Cologne
|
||||||
|
e.V. <https://koeln.ccc.de>`__ in Cologne, Germany
|
||||||
|
- 2015-08-23: `A Solution to the Backup
|
||||||
|
Inconvenience <https://programm.froscon.de/2015/events/1515.html>`__:
|
||||||
|
Lecture at `FROSCON 2015 <https://www.froscon.de>`__ in Bonn, Germany
|
||||||
|
- 2015-02-01: `Lightning Talk at FOSDEM
|
||||||
|
2015 <https://www.youtube.com/watch?v=oM-MfeflUZ8&t=11m40s>`__: A
|
||||||
|
short introduction (with slightly outdated command line)
|
||||||
|
- 2015-01-27: `Talk about restic at CCC
|
||||||
|
Aachen <https://videoag.fsmpi.rwth-aachen.de/?view=player&lectureid=4442#content>`__
|
||||||
|
(in German)
|
|
@ -1 +0,0 @@
|
||||||
design.rst
|
|
|
@ -4,12 +4,16 @@ Restic Documentation
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
installation
|
010_introduction
|
||||||
manual
|
020_installation
|
||||||
|
030_preparing_a_new_repo
|
||||||
|
040_backup
|
||||||
|
045_working_with_repos
|
||||||
|
050_restore
|
||||||
|
060_forget
|
||||||
|
070_encryption
|
||||||
|
080_examples
|
||||||
|
090_participating
|
||||||
|
100_references
|
||||||
faq
|
faq
|
||||||
tutorials
|
manual_rest
|
||||||
development
|
|
||||||
references
|
|
||||||
talks
|
|
||||||
|
|
||||||
.. include:: ../README.rst
|
|
||||||
|
|
|
@ -1,79 +0,0 @@
|
||||||
Installation
|
|
||||||
============
|
|
||||||
|
|
||||||
Packages
|
|
||||||
--------
|
|
||||||
|
|
||||||
Mac OS X
|
|
||||||
~~~~~~~~~
|
|
||||||
|
|
||||||
If you are using Mac OS X, you can install restic using the
|
|
||||||
`homebrew <http://brew.sh/>`__ package manager:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ brew tap restic/restic
|
|
||||||
$ brew install restic
|
|
||||||
|
|
||||||
Arch Linux
|
|
||||||
~~~~~~~~~~
|
|
||||||
|
|
||||||
On `Arch Linux <https://www.archlinux.org/>`__, there is a package called ``restic-git`` which can be
|
|
||||||
installed from AUR, e.g. with ``pacaur``:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ pacaur -S restic-git
|
|
||||||
|
|
||||||
Nix & NixOS
|
|
||||||
~~~~~~~~~~~
|
|
||||||
|
|
||||||
If you are using `Nix <https://nixos.org/nix/>`__ or `NixOS <https://nixos.org/>`__
|
|
||||||
there is a package available named ``restic``.
|
|
||||||
It can be installed uisng ``nix-env``:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ nix-env --install restic
|
|
||||||
|
|
||||||
Pre-compiled Binary
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
You can download the latest pre-compiled binary from the `restic release
|
|
||||||
page <https://github.com/restic/restic/releases/latest>`__.
|
|
||||||
|
|
||||||
From Source
|
|
||||||
-----------
|
|
||||||
|
|
||||||
restic is written in the Go programming language and you need at least
|
|
||||||
Go version 1.8. Building restic may also work with older versions of Go,
|
|
||||||
but that's not supported. See the `Getting
|
|
||||||
started <https://golang.org/doc/install>`__ guide of the Go project for
|
|
||||||
instructions how to install Go.
|
|
||||||
|
|
||||||
In order to build restic from source, execute the following steps:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
$ git clone https://github.com/restic/restic
|
|
||||||
[...]
|
|
||||||
|
|
||||||
$ cd restic
|
|
||||||
|
|
||||||
$ go run build.go
|
|
||||||
|
|
||||||
You can easily cross-compile restic for all supported platforms, just
|
|
||||||
supply the target OS and platform via the command-line options like this
|
|
||||||
(for Windows and FreeBSD respectively):
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
$ go run build.go --goos windows --goarch amd64
|
|
||||||
|
|
||||||
$ go run build.go --goos freebsd --goarch 386
|
|
||||||
|
|
||||||
The resulting binary is statically linked and does not require any
|
|
||||||
libraries.
|
|
||||||
|
|
||||||
At the moment, the only tested compiler for restic is the official Go
|
|
||||||
compiler. Building restic with gccgo may work, but is not supported.
|
|
1265
doc/manual.rst
1265
doc/manual.rst
File diff suppressed because it is too large
Load diff
278
doc/manual_rest.rst
Normal file
278
doc/manual_rest.rst
Normal file
|
@ -0,0 +1,278 @@
|
||||||
|
Manual
|
||||||
|
======
|
||||||
|
|
||||||
|
Usage help
|
||||||
|
----------
|
||||||
|
|
||||||
|
Usage help is available:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ ./restic --help
|
||||||
|
restic is a backup program which allows saving multiple revisions of files and
|
||||||
|
directories 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 information
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ ./restic backup --help
|
||||||
|
The "backup" command creates a new snapshot and saves the files and directories
|
||||||
|
given 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.
|
||||||
|
|
||||||
|
Manage tags
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Managing tags on snapshots is done with the ``tag`` command. The
|
||||||
|
existing set of tags can be replaced completely, tags can be added to
|
||||||
|
removed. The result is directly visible in the ``snapshots`` command.
|
||||||
|
|
||||||
|
Let's say we want to tag snapshot ``590c8fc8`` with the tags ``NL`` and
|
||||||
|
``CH`` and remove all other tags that may be present, the following
|
||||||
|
command does that:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup tag --set NL --set CH 590c8fc8
|
||||||
|
Create exclusive lock for repository
|
||||||
|
Modified tags on 1 snapshots
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
So we can add and remove tags incrementally like this:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup tag --tag NL --remove CH
|
||||||
|
Create exclusive lock for repository
|
||||||
|
Modified tags on 1 snapshots
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup tag --tag NL --add UK
|
||||||
|
Create exclusive lock for repository
|
||||||
|
Modified tags on 1 snapshots
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup tag --tag NL --remove NL
|
||||||
|
Create exclusive lock for repository
|
||||||
|
Modified tags on 1 snapshots
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup tag --tag NL --add SOMETHING
|
||||||
|
No snapshots were modified
|
||||||
|
|
||||||
|
Under the hood
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Browse repository objects
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Internally, a repository stores data of several different types
|
||||||
|
described in the `design
|
||||||
|
documentation <https://github.com/restic/restic/blob/master/doc/Design.rst>`__.
|
||||||
|
You can ``list`` objects such as blobs, packs, index, snapshots, keys or
|
||||||
|
locks with the following command:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup list snapshots
|
||||||
|
d369ccc7d126594950bf74f0a348d5d98d9e99f3215082eb69bf02dc9b3e464c
|
||||||
|
|
||||||
|
The ``find`` command searches for a given
|
||||||
|
`pattern <http://golang.org/pkg/path/filepath/#Match>`__ in the
|
||||||
|
repository.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r backup find test.txt
|
||||||
|
debug log file restic.log
|
||||||
|
debug enabled
|
||||||
|
enter password for repository:
|
||||||
|
found 1 matching entries in snapshot 196bc5760c909a7681647949e80e5448e276521489558525680acf1bd428af36
|
||||||
|
-rw-r--r-- 501 20 5 2015-08-26 14:09:57 +0200 CEST path/to/test.txt
|
||||||
|
|
||||||
|
The ``cat`` command allows you to display the JSON representation of the
|
||||||
|
objects or its raw content.
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup cat snapshot d369ccc7d126594950bf74f0a348d5d98d9e99f3215082eb69bf02dc9b3e464c
|
||||||
|
enter password for repository:
|
||||||
|
{
|
||||||
|
"time": "2015-08-12T12:52:44.091448856+02:00",
|
||||||
|
"tree": "05cec17e8d3349f402576d02576a2971fc0d9f9776ce2f441c7010849c4ff5af",
|
||||||
|
"paths": [
|
||||||
|
"/home/user/work"
|
||||||
|
],
|
||||||
|
"hostname": "kasimir",
|
||||||
|
"username": "username",
|
||||||
|
"uid": 501,
|
||||||
|
"gid": 20
|
||||||
|
}
|
||||||
|
|
||||||
|
Metadata handling
|
||||||
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Restic saves and restores most default attributes, including extended attributes like ACLs.
|
||||||
|
Sparse files are not handled in a special way yet, and aren't restored.
|
||||||
|
|
||||||
|
The following metadata is handled by restic:
|
||||||
|
|
||||||
|
- Name
|
||||||
|
- Type
|
||||||
|
- Mode
|
||||||
|
- ModTime
|
||||||
|
- AccessTime
|
||||||
|
- ChangeTime
|
||||||
|
- UID
|
||||||
|
- GID
|
||||||
|
- User
|
||||||
|
- Group
|
||||||
|
- Inode
|
||||||
|
- Size
|
||||||
|
- Links
|
||||||
|
- LinkTarget
|
||||||
|
- Device
|
||||||
|
- Content
|
||||||
|
- Subtree
|
||||||
|
- ExtendedAttributes
|
||||||
|
|
||||||
|
Scripting
|
||||||
|
---------
|
||||||
|
|
||||||
|
Restic supports the output of some commands in JSON format, the JSON
|
||||||
|
data can then be processed by other programs (e.g.
|
||||||
|
`jq <https://stedolan.github.io/jq/>`__). The following example
|
||||||
|
lists all snapshots as JSON and uses ``jq`` to pretty-print the result:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ restic -r /tmp/backup snapshots --json | jq .
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"time": "2017-03-11T09:57:43.26630619+01:00",
|
||||||
|
"tree": "bf25241679533df554fc0fd0ae6dbb9dcf1859a13f2bc9dd4543c354eff6c464",
|
||||||
|
"paths": [
|
||||||
|
"/home/work/doc"
|
||||||
|
],
|
||||||
|
"hostname": "kasimir",
|
||||||
|
"username": "fd0",
|
||||||
|
"uid": 1000,
|
||||||
|
"gid": 100,
|
||||||
|
"id": "bbeed6d28159aa384d1ccc6fa0b540644b1b9599b162d2972acda86b1b80f89e"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"time": "2017-03-11T09:58:57.541446938+01:00",
|
||||||
|
"tree": "7f8c95d3420baaac28dc51609796ae0e0ecfb4862b609a9f38ffaf7ae2d758da",
|
||||||
|
"paths": [
|
||||||
|
"/home/user/shared"
|
||||||
|
],
|
||||||
|
"hostname": "kasimir",
|
||||||
|
"username": "fd0",
|
||||||
|
"uid": 1000,
|
||||||
|
"gid": 100,
|
||||||
|
"id": "b157d91c16f0ba56801ece3a708dfc53791fe2a97e827090d6ed9a69a6ebdca0"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
|
||||||
|
Temporary files
|
||||||
|
---------------
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
$ export TMPDIR=/var/tmp/restic-tmp
|
||||||
|
$ restic -r /tmp/backup backup ~/work
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Caching
|
||||||
|
-------
|
||||||
|
|
||||||
|
Restic keeps a cache with some files from the repository on the local machine.
|
||||||
|
This allows faster operations, since meta data does not need to be loaded from
|
||||||
|
a remote repository. The cache is automatically created, usually in the
|
||||||
|
directory ``.cache/restic`` in the user's home directory. The environment
|
||||||
|
variable ``XDG_CACHE_DIR`` or the command line parameter ``--cache-dir`` can
|
||||||
|
each be used to specify where the cache is located. The parameter
|
||||||
|
``--no-cache`` disables the cache entirely. In this case, all data is loaded
|
||||||
|
from the repo.
|
||||||
|
|
||||||
|
The cache is ephemeral: When a file cannot be read from the cache, it is loaded
|
||||||
|
from the repository.
|
|
@ -1,13 +0,0 @@
|
||||||
==========
|
|
||||||
References
|
|
||||||
==========
|
|
||||||
|
|
||||||
.. include:: design.rst
|
|
||||||
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
.. include:: rest_backend.rst
|
|
||||||
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
.. include:: cache.rst
|
|
|
@ -1,84 +0,0 @@
|
||||||
REST Backend
|
|
||||||
============
|
|
||||||
|
|
||||||
Restic can interact with HTTP Backend that respects the following REST
|
|
||||||
API. The following values are valid for ``{type}``: ``data``, ``keys``,
|
|
||||||
``locks``, ``snapshots``, ``index``, ``config``. ``{path}`` is a path to
|
|
||||||
the repository, so that multiple different repositories can be accessed.
|
|
||||||
The default path is ``/``.
|
|
||||||
|
|
||||||
POST {path}?create=true
|
|
||||||
-----------------------
|
|
||||||
|
|
||||||
This request is used to initially create a new repository. The server
|
|
||||||
responds with "200 OK" if the repository structure was created
|
|
||||||
successfully or already exists, otherwise an error is returned.
|
|
||||||
|
|
||||||
DELETE {path}
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Deletes the repository on the server side. The server responds with "200
|
|
||||||
OK" if the repository was successfully removed. If this function is not
|
|
||||||
implemented the server returns "501 Not Implemented", if this it is
|
|
||||||
denied by the server it returns "403 Forbidden".
|
|
||||||
|
|
||||||
HEAD {path}/config
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Returns "200 OK" if the repository has a configuration, an HTTP error
|
|
||||||
otherwise.
|
|
||||||
|
|
||||||
GET {path}/config
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Returns the content of the configuration file if the repository has a
|
|
||||||
configuration, an HTTP error otherwise.
|
|
||||||
|
|
||||||
Response format: binary/octet-stream
|
|
||||||
|
|
||||||
POST {path}/config
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Returns "200 OK" if the configuration of the request body has been
|
|
||||||
saved, an HTTP error otherwise.
|
|
||||||
|
|
||||||
GET {path}/{type}/
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Returns a JSON array containing the names of all the blobs stored for a
|
|
||||||
given type.
|
|
||||||
|
|
||||||
Response format: JSON
|
|
||||||
|
|
||||||
HEAD {path}/{type}/{name}
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
Returns "200 OK" if the blob with the given name and type is stored in
|
|
||||||
the repository, "404 not found" otherwise. If the blob exists, the HTTP
|
|
||||||
header ``Content-Length`` is set to the file size.
|
|
||||||
|
|
||||||
GET {path}/{type}/{name}
|
|
||||||
------------------------
|
|
||||||
|
|
||||||
Returns the content of the blob with the given name and type if it is
|
|
||||||
stored in the repository, "404 not found" otherwise.
|
|
||||||
|
|
||||||
If the request specifies a partial read with a Range header field, then
|
|
||||||
the status code of the response is 206 instead of 200 and the response
|
|
||||||
only contains the specified range.
|
|
||||||
|
|
||||||
Response format: binary/octet-stream
|
|
||||||
|
|
||||||
POST {path}/{type}/{name}
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
Saves the content of the request body as a blob with the given name and
|
|
||||||
type, an HTTP error otherwise.
|
|
||||||
|
|
||||||
Request format: binary/octet-stream
|
|
||||||
|
|
||||||
DELETE {path}/{type}/{name}
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
Returns "200 OK" if the blob with the given name and type has been
|
|
||||||
deleted from the repository, an HTTP error otherwise.
|
|
|
@ -1,20 +0,0 @@
|
||||||
Talks
|
|
||||||
=====
|
|
||||||
|
|
||||||
The following talks will be or have been given about restic:
|
|
||||||
|
|
||||||
- 2016-01-31: Lightning Talk at the Go Devroom at FOSDEM 2016,
|
|
||||||
Brussels, Belgium
|
|
||||||
- 2016-01-29: `restic - Backups mal
|
|
||||||
richtig <https://media.ccc.de/v/c4.openchaos.2016.01.restic>`__:
|
|
||||||
Public lecture in German at `CCC Cologne
|
|
||||||
e.V. <https://koeln.ccc.de>`__ in Cologne, Germany
|
|
||||||
- 2015-08-23: `A Solution to the Backup
|
|
||||||
Inconvenience <https://programm.froscon.de/2015/events/1515.html>`__:
|
|
||||||
Lecture at `FROSCON 2015 <https://www.froscon.de>`__ in Bonn, Germany
|
|
||||||
- 2015-02-01: `Lightning Talk at FOSDEM
|
|
||||||
2015 <https://www.youtube.com/watch?v=oM-MfeflUZ8&t=11m40s>`__: A
|
|
||||||
short introduction (with slightly outdated command line)
|
|
||||||
- 2015-01-27: `Talk about restic at CCC
|
|
||||||
Aachen <https://videoag.fsmpi.rwth-aachen.de/?view=player&lectureid=4442#content>`__
|
|
||||||
(in German)
|
|
|
@ -1,5 +0,0 @@
|
||||||
==========
|
|
||||||
Tutorials
|
|
||||||
==========
|
|
||||||
|
|
||||||
.. include:: tutorial_aws_s3.rst
|
|
Loading…
Reference in a new issue