diff --git a/borg/repository.py b/borg/repository.py index a3d8c07eb..2985593f8 100644 --- a/borg/repository.py +++ b/borg/repository.py @@ -1,5 +1,6 @@ from configparser import ConfigParser from binascii import hexlify, unhexlify +from datetime import datetime from itertools import islice import errno import logging @@ -217,10 +218,8 @@ def write_index(self): os.rename(os.path.join(self.path, 'index.tmp'), os.path.join(self.path, 'index.%d' % transaction_id)) if self.append_only: - transaction_log = os.path.join(self.path, 'transactions') - if not os.path.exists(transaction_log): - os.mkdir(transaction_log) - open(os.path.join(transaction_log, str(transaction_id)), 'w').close() + with open(os.path.join(self.path, 'transactions'), 'a') as log: + print('transaction %d, UTC time %s' % (transaction_id, datetime.utcnow().isoformat()), file=log) # Remove old indices current = '.%d' % transaction_id for name in os.listdir(self.path): @@ -333,6 +332,8 @@ def check(self, repair=False, save_space=False): This method verifies all segment checksums and makes sure the index is consistent with the data stored in the segments. """ + if self.append_only and repair: + raise ValueError(self.path + " is in append-only mode") error_found = False def report_error(msg): diff --git a/docs/usage.rst b/docs/usage.rst index a016e008a..fb566ab3b 100644 --- a/docs/usage.rst +++ b/docs/usage.rst @@ -694,3 +694,71 @@ Now, let's see how to restore some LVs from such a backup. :: $ # we assume that you created an empty root and home LV and overwrite it now: $ borg extract --stdout /mnt/backup::repo dev/vg0/root-snapshot > /dev/vg0/root $ borg extract --stdout /mnt/backup::repo dev/vg0/home-snapshot > /dev/vg0/home + + +Append-only mode +~~~~~~~~~~~~~~~~ + +A repository can be made "append-only", which means that Borg will never overwrite or +delete committed data. This is useful for scenarios where multiple machines back up to +a central backup server using ``borg serve``, since a hacked machine cannot delete +backups permanently. + +To activate append-only mode, edit the repository ``config`` file and add a line +``append_only=1`` to the ``[repository]`` section (or edit the line if it exists). + +In append-only mode Borg will create a transaction log in the ``transactions`` file, +where each line is a transaction and a UTC timestamp. + +Example ++++++++ + +Suppose an attacker remotely deleted all backups, but your repository was in append-only +mode. A transaction look in this situation might look like this: :: + + transaction 1, UTC time 2016-03-31T15:53:27.383532 + transaction 5, UTC time 2016-03-31T15:53:52.588922 + transaction 11, UTC time 2016-03-31T15:54:23.887256 + transaction 12, UTC time 2016-03-31T15:55:54.022540 + transaction 13, UTC time 2016-03-31T15:55:55.472564 + +From your security logs you conclude the attacker gained access at 15:54:00 and all +the backups where deleted or replaced by compromised backups. From the log you know +that transactions 11 and later are compromised. Note that the transaction ID is the +name of the *last* file in the transaction. For example, transaction 11 spans files 6 +to 11. + +The first step to reset the repository to transaction 5, the last uncompromised transaction, +is to remove the ``hints.N`` and ``index.N`` files in the repository (these two files are +always expendable). In this example N is 13. + +Then remove or move all segment files from the segment directories in ``data/`` starting +with file 6:: + + rm data/**/{6..13} + +That's all to it. In a real attack you'll likely want to keep the compromised repository +intact to analyze what the attacker tried to achieve. It's also a good idea to make this +copy just in case something goes wrong during the recovery. + +Drawbacks ++++++++++ + +As data is only appended, and nothing deleted, commands like ``prune`` or ``delete`` +won't free disk space, they merely tag data as deleted in a new transaction. + +Note that you can go back-and-forth between normal and append-only operation by editing +the configuration file, it's not a "one way trip". + +Further considerations +++++++++++++++++++++++ + +Append-only mode is not respected by tools other than Borg. ``rm`` still works on the +repository. Make sure that backup jobs only get to access the repository with ``borg serve``. + +Ensure that no remote access is possible if the repository is temporarily set to normal mode +for e.g. regular pruning. + +Further protections can be implemented, but are outside of Borgs scope. For example, +file system snapshots or wrapping ``borg serve`` to set special permissions or ACLs on +new data files. \ No newline at end of file