Jelajahi Sumber

backport some FAQ entries from master branch

Thomas Waldmann 9 tahun lalu
induk
melakukan
1fe3781186
2 mengubah file dengan 48 tambahan dan 3 penghapusan
  1. 46 3
      docs/faq.rst
  2. 2 0
      docs/usage.rst

+ 46 - 3
docs/faq.rst

@@ -133,6 +133,50 @@ into the repository.
 Yes, as an attacker with access to the remote server could delete (or
 Yes, as an attacker with access to the remote server could delete (or
 otherwise make unavailable) all your backups.
 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?
 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
 stops after a while (some minutes, hours, ... - not immediately) with
 "connection closed by remote" error message. Why?
 "connection closed by remote" error message. Why?
 
 
-That's a good question and we are trying to find a good answer in
-`ticket 636 <https://github.com/borgbackup/borg/issues/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?
 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
 So, if you need that, consider RAID or a filesystem that offers redundant
 storage or just make backups to different locations / different hardware.
 storage or just make backups to different locations / different hardware.
 
 
-See also `ticket 225 <https://github.com/borgbackup/borg/issues/225>`_.
+See also :issue:`225`.
 
 
 Can |project_name| verify data integrity of a backup archive?
 Can |project_name| verify data integrity of a backup archive?
 -------------------------------------------------------------
 -------------------------------------------------------------

+ 2 - 0
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
     $ borg extract --stdout /path/to/repo::arch dev/vg0/home-snapshot > /dev/vg0/home
 
 
 
 
+.. _append_only_mode:
+
 Append-only mode
 Append-only mode
 ~~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~~