2013-06-29 21:56:44 +00:00
|
|
|
.. _faq:
|
|
|
|
.. include:: global.rst.inc
|
|
|
|
|
|
|
|
Frequently asked questions
|
|
|
|
==========================
|
|
|
|
|
|
|
|
Which platforms are supported?
|
2013-07-31 18:51:01 +00:00
|
|
|
Currently Linux, FreeBSD and MacOS X are supported.
|
2013-07-30 19:51:21 +00:00
|
|
|
|
2015-05-14 18:47:08 +00:00
|
|
|
You can try your luck on other POSIX-like systems, like Cygwin,
|
|
|
|
other BSDs, etc. but they are not officially supported.
|
2013-06-29 21:56:44 +00:00
|
|
|
|
|
|
|
Can I backup VM disk images?
|
2013-07-31 18:51:01 +00:00
|
|
|
Yes, the :ref:`deduplication <deduplication_def>` technique used by |project_name|
|
|
|
|
makes sure only the modified parts of the file are stored.
|
2015-05-14 18:47:08 +00:00
|
|
|
Also, we have optional simple sparse file support for extract.
|
2013-07-30 19:51:21 +00:00
|
|
|
|
2014-12-16 16:16:30 +00:00
|
|
|
Can I backup from multiple servers into a single repository?
|
2015-05-22 21:56:29 +00:00
|
|
|
Yes, but in order for the deduplication used by |project_name| to work, it
|
2014-12-16 16:16:30 +00:00
|
|
|
needs to keep a local cache containing checksums of all file
|
|
|
|
chunks already stored in the repository. This cache is stored in
|
2015-05-22 21:56:29 +00:00
|
|
|
``~/.cache/borg/``. If |project_name| detects that a repository has been
|
2014-12-16 16:16:30 +00:00
|
|
|
modified since the local cache was updated it will need to rebuild
|
|
|
|
the cache. This rebuild can be quite time consuming.
|
|
|
|
|
|
|
|
So, yes it's possible. But it will be most efficient if a single
|
2015-03-05 14:06:20 +00:00
|
|
|
repository is only modified from one place. Also keep in mind that
|
2015-05-22 21:56:29 +00:00
|
|
|
|project_name| will keep an exclusive lock on the repository while creating
|
2015-03-05 14:06:20 +00:00
|
|
|
or deleting archives, which may make *simultaneous* backups fail.
|
2014-12-16 16:16:30 +00:00
|
|
|
|
2015-05-14 16:48:14 +00:00
|
|
|
Which file types, attributes, etc. are preserved?
|
|
|
|
* Directories
|
|
|
|
* Regular files
|
|
|
|
* Hardlinks (considering all files in the same archive)
|
|
|
|
* Symlinks (stored as symlink, the symlink is not followed)
|
|
|
|
* Character and block device files
|
|
|
|
* FIFOs ("named pipes")
|
2013-07-31 18:51:01 +00:00
|
|
|
* Name
|
|
|
|
* Contents
|
|
|
|
* Time of last modification (nanosecond precision with Python >= 3.3)
|
|
|
|
* User ID of owner
|
|
|
|
* Group ID of owner
|
2015-05-14 16:48:14 +00:00
|
|
|
* Unix Mode/Permissions (u/g/o permissions, suid, sgid, sticky)
|
|
|
|
* Extended Attributes (xattrs)
|
2014-05-03 21:27:01 +00:00
|
|
|
* Access Control Lists (ACL_) on Linux, OS X and FreeBSD
|
|
|
|
* BSD flags on OS X and FreeBSD
|
2013-07-30 19:51:21 +00:00
|
|
|
|
2015-05-14 16:48:14 +00:00
|
|
|
Which file types, attributes, etc. are *not* preserved?
|
|
|
|
* UNIX domain sockets (because it does not make sense - they are meaningless
|
|
|
|
without the running process that created them and the process needs to
|
|
|
|
recreate them in any case). So, don't panic if your backup misses a UDS!
|
|
|
|
* The precise on-disk representation of the holes in a sparse file.
|
|
|
|
Archive creation has no special support for sparse files, holes are
|
2015-06-11 20:18:12 +00:00
|
|
|
backed up as (deduplicated and compressed) runs of zero bytes.
|
2015-05-14 16:48:14 +00:00
|
|
|
Archive extraction has optional support to extract all-zero chunks as
|
|
|
|
holes in a sparse file.
|
|
|
|
|
2013-07-30 19:51:21 +00:00
|
|
|
How can I specify the encryption passphrase programmatically?
|
2013-07-31 18:51:01 +00:00
|
|
|
The encryption passphrase can be specified programmatically using the
|
2015-05-09 16:40:55 +00:00
|
|
|
`BORG_PASSPHRASE` environment variable. This is convenient when setting up
|
2013-07-31 18:51:01 +00:00
|
|
|
automated encrypted backups. Another option is to use
|
|
|
|
key file based encryption with a blank passphrase. See
|
|
|
|
:ref:`encrypted_repos` for more details.
|
2014-04-05 19:08:11 +00:00
|
|
|
|
2015-05-22 21:56:29 +00:00
|
|
|
When backing up to remote encrypted repos, is encryption done locally?
|
|
|
|
Yes, file and directory metadata and data is locally encrypted, before
|
|
|
|
leaving the local machine. We do not mean the transport layer encryption
|
|
|
|
by that, but the data/metadata itself. Transport layer encryption (e.g.
|
|
|
|
when ssh is used as a transport) applies additionally.
|
|
|
|
|
|
|
|
When backing up to remote servers, do I have to trust the remote server?
|
|
|
|
Yes and No.
|
2015-07-14 19:31:35 +00:00
|
|
|
No, as far as data confidentiality is concerned - if you use encryption,
|
|
|
|
all your files/dirs data and metadata are stored in their encrypted form
|
|
|
|
into the repository.
|
2015-05-22 21:56:29 +00:00
|
|
|
Yes, as an attacker with access to the remote server could delete (or
|
|
|
|
otherwise make unavailable) all your backups.
|
2014-04-05 19:08:11 +00:00
|
|
|
|
2015-05-14 18:47:08 +00:00
|
|
|
If a backup stops mid-way, does the already-backed-up data stay there? I.e. does |project_name| resume backups?
|
2014-12-25 12:21:42 +00:00
|
|
|
Yes, during a backup a special checkpoint archive named ``<archive-name>.checkpoint`` is saved every 5 minutes
|
2014-04-05 19:08:11 +00:00
|
|
|
containing all the data backed-up until that point. This means that at most 5 minutes worth of data needs to be
|
|
|
|
retransmitted if a backup needs to be restarted.
|
2015-05-14 18:47:08 +00:00
|
|
|
|
|
|
|
If it crashes with a UnicodeError, what can I do?
|
|
|
|
Check if your encoding is set correctly. For most POSIX-like systems, try::
|
|
|
|
|
2015-05-14 23:50:45 +00:00
|
|
|
export LANG=en_US.UTF-8 # or similar, important is correct charset
|
2015-05-14 18:47:08 +00:00
|
|
|
|
2015-05-22 21:56:29 +00:00
|
|
|
If I want to run |project_name| on a ARM CPU older than ARM v6?
|
2015-05-22 22:15:58 +00:00
|
|
|
You need to enable the alignment trap handler to fixup misaligned accesses::
|
2015-05-22 21:56:29 +00:00
|
|
|
|
|
|
|
echo "2" > /proc/cpu/alignment
|
|
|
|
|
2015-07-14 19:31:35 +00:00
|
|
|
Can |project_name| add redundancy to the backup data to deal with hardware malfunction?
|
|
|
|
No, it can't. While that at first sounds like a good idea to defend against some
|
|
|
|
defect HDD sectors or SSD flash blocks, dealing with this in a reliable way needs a lot
|
|
|
|
of low-level storage layout information and control which we do not have (and also can't
|
|
|
|
get, even if we wanted).
|
|
|
|
|
|
|
|
So, if you need that, consider RAID1 or a filesystems that offers redundant storage.
|
|
|
|
|
|
|
|
Can |project_name| verify data integrity of a backup archive?
|
|
|
|
Yes, if you want to detect accidental data damage (like bit rot), use the ``check``
|
|
|
|
operation. It will notice corruption using CRCs and hashes.
|
|
|
|
If you want to be able to detect malicious tampering also, use a encrypted repo.
|
|
|
|
It will then be able to check using CRCs and HMACs.
|
|
|
|
|
2015-05-22 20:09:38 +00:00
|
|
|
Why was Borg forked from Attic?
|
2015-05-22 21:56:29 +00:00
|
|
|
Borg was created in May 2015 in response to the difficulty of
|
|
|
|
getting new code or larger changes incorporated into Attic and
|
|
|
|
establishing a bigger developer community / more open development.
|
|
|
|
|
|
|
|
More details can be found in `ticket 217
|
2015-05-22 22:15:58 +00:00
|
|
|
<https://github.com/jborg/attic/issues/217>`_ that led to the fork.
|
2015-05-22 01:55:29 +00:00
|
|
|
|
2015-05-22 20:09:38 +00:00
|
|
|
Borg intends to be:
|
2015-05-22 01:55:29 +00:00
|
|
|
|
|
|
|
* simple:
|
2015-05-22 22:15:58 +00:00
|
|
|
|
2015-05-22 01:55:29 +00:00
|
|
|
* as simple as possible, but no simpler
|
|
|
|
* do the right thing by default, but offer options
|
|
|
|
* open:
|
2015-05-22 22:15:58 +00:00
|
|
|
|
2015-05-22 01:55:29 +00:00
|
|
|
* welcome feature requests
|
|
|
|
* accept pull requests of good quality and coding style
|
|
|
|
* give feedback on PRs that can't be accepted "as is"
|
|
|
|
* discuss openly, don't work in the dark
|
|
|
|
* changing:
|
2015-05-22 22:15:58 +00:00
|
|
|
|
2015-05-22 21:56:29 +00:00
|
|
|
* Borg is not compatible with Attic
|
2015-05-22 01:55:29 +00:00
|
|
|
* do not break compatibility accidentally, without a good reason
|
2015-05-22 21:56:29 +00:00
|
|
|
or without warning. allow compatibility breaking for other cases.
|
|
|
|
* if major version number changes, it may have incompatible changes
|