backupninja/FAQ.md

70 lines
2.7 KiB
Markdown
Raw Normal View History

2017-02-17 09:49:06 +01:00
duplicity works fine when run standalone, but complains about gpg "public key not found" when run from backupninja
==================================================================================================================
We bet you're using sudo to run both duplicity and backupninja, and have been
using sudo as well when generating the GnuPG key pair used by duplicity.
Quick fix: generate a new GnuPG key pair in a root shell, or using
`sudo -H` instead of plain sudo.
Another solution: import the GnuPG keypair into the root user's keyring, taking
care of running `gpg --update-trustdb` in a root shell or using `sudo -H`
afterwards, in order to tag this keypair as "ultimately trusted".
Detailed explanation: sudo does not change `$HOME` by default, so GnuPG saved the
newly generated key pair to your own keyring, rather than to the root user's
keyring. Running `sudo duplicity` hides the problem, as it uses your own
keyring. Running `sudo backupninja` reveals the problem, as backupninja uses
`su` to make sure it runs duplicity in a real root environment, i.e. using the
root user's GnuPG keyring.
What should I do when rdiff-backup fails?
=========================================
If rdiff-backup fails, the meta data file may get corrupt. When this
happens, rdiff-backup will complain loudly every time it is run and
possibly fail to backup some or all the files.
To force rdiff-backup to rebuild the meta data, set this option in
the `.rdiff` backup action file:
options = --force
After a rdiff-backup run has been successful you should remove
this option.
How to restrict privileges on the backup server?
================================================
backupninja uses a "push" mechanism, where backups are sent from one
or several hosts to a centralized backup server.
Mount your backup partition with limited execution rights
---------------------------------------------------------
Edit `/etc/fstab` to mount your partition with limited rights. For example:
/home ext3 defaults,nosuid,noexec,nodev 0 2
Create a user for each client
-----------------------------
On the backup server, it is important to create a separate user for
each client.
Use a restricted shell and jail users
-------------------------------------
Furthermore, you may use a restricted shell like
[rssh](http://www.pizzashack.org/rssh/index.shtml) or
[scponly](http://sublimation.org/scponly/wiki/index.php/Main_Page),
which also offer the ability to jail connections.
On the backup server:
$ apt-get install scponly
$ adduser --disabled-password --home /home/backup/ninja-host1 --shell /usr/bin/scponly ninja-host1
You may now use `ninja-host1` user to connect to the
`/home/backup/ninja-host1` jail.