From 1fe3781186bf67f44f5bd77b0da557366fe544c7 Mon Sep 17 00:00:00 2001 From: Thomas Waldmann Date: Thu, 7 Jul 2016 21:56:06 +0200 Subject: [PATCH] backport some FAQ entries from master branch --- docs/faq.rst | 49 ++++++++++++++++++++++++++++++++++++++++++++++--- docs/usage.rst | 2 ++ 2 files changed, 48 insertions(+), 3 deletions(-) diff --git a/docs/faq.rst b/docs/faq.rst index ff0e88ad3..3effa0002 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -133,6 +133,50 @@ into the repository. Yes, as an attacker with access to the remote server could delete (or otherwise make unavailable) all your backups. +How can I protect against a hacked backup client? +------------------------------------------------- + +Assume you backup your backup client machine C to the backup server S and +C gets hacked. In a simple push setup, the attacker could then use borg on +C to delete all backups residing on S. + +These are your options to protect against that: + +- Do not allow to permanently delete data from the repo, see :ref:`append_only_mode`. +- Use a pull-mode setup using ``ssh -R``, see :issue:`900`. +- Mount C's filesystem on another machine and then create a backup of it. +- Do not give C filesystem-level access to S. + +How can I protect against a hacked backup server? +------------------------------------------------- + +Just in case you got the impression that pull-mode backups are way more safe +than push-mode, you also need to consider the case that your backup server S +gets hacked. In case S has access to a lot of clients C, that might bring you +into even bigger trouble than a hacked backup client in the previous FAQ entry. + +These are your options to protect against that: + +- Use the standard push-mode setup (see also previous FAQ entry). +- Mount (the repo part of) S's filesystem on C. +- Do not give S file-system level access to C. +- Have your backup server at a well protected place (maybe not reachable from + the internet), configure it safely, apply security updates, monitor it, ... + +How can I protect against theft, sabotage, lightning, fire, ...? +---------------------------------------------------------------- + +In general: if your only backup medium is nearby the backupped machine and +always connected, you can easily get into trouble: they likely share the same +fate if something goes really wrong. + +Thus: + +- have multiple backup media +- have media disconnected from network, power, computer +- have media at another place +- have a relatively recent backup on your media + Why do I get "connection closed by remote" after a while? --------------------------------------------------------- @@ -140,8 +184,7 @@ When doing a backup to a remote server (using a ssh: repo URL), it sometimes stops after a while (some minutes, hours, ... - not immediately) with "connection closed by remote" error message. Why? -That's a good question and we are trying to find a good answer in -`ticket 636 `_. +That's a good question and we are trying to find a good answer in :issue:`636`. Why am I seeing idle borg serve processes on the repo server? ------------------------------------------------------------- @@ -275,7 +318,7 @@ control which we do not have (and also can't get, even if we wanted). So, if you need that, consider RAID or a filesystem that offers redundant storage or just make backups to different locations / different hardware. -See also `ticket 225 `_. +See also :issue:`225`. Can |project_name| verify data integrity of a backup archive? ------------------------------------------------------------- diff --git a/docs/usage.rst b/docs/usage.rst index 8b5dd50b3..443eda1c1 100644 --- a/docs/usage.rst +++ b/docs/usage.rst @@ -718,6 +718,8 @@ Now, let's see how to restore some LVs from such a backup. :: $ borg extract --stdout /path/to/repo::arch dev/vg0/home-snapshot > /dev/vg0/home +.. _append_only_mode: + Append-only mode ~~~~~~~~~~~~~~~~