1
0
Fork 0
mirror of https://github.com/borgbackup/borg.git synced 2024-12-25 09:19:31 +00:00

Merge pull request #1283 from ThomasWaldmann/backports-from-master-faq

backport some FAQ entries from master branch
This commit is contained in:
TW 2016-07-07 22:17:14 +02:00 committed by GitHub
commit 88e7b5331a
2 changed files with 48 additions and 3 deletions

View file

@ -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 That's a good question and we are trying to find a good answer in :issue:`636`.
`ticket 636 <https://github.com/borgbackup/borg/issues/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?
------------------------------------------------------------- -------------------------------------------------------------

View file

@ -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
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~