.. include:: global.rst.inc
.. highlight:: none
.. _faq:
Frequently asked questions
==========================
Usage & Limitations
###################
What is the difference between a repo on an external hard drive vs. repo on a server?
-------------------------------------------------------------------------------------
If Borg is running in client/server mode, the client uses SSH as a transport to
talk to the remote agent, which is another Borg process (Borg is installed on
the server, too) started automatically by the client. The Borg server is doing
storage-related low-level repo operations (get, put, commit, check, compact),
while the Borg client does the high-level stuff: deduplication, encryption,
compression, dealing with archives, backups, restores, etc., which reduces the
amount of data that goes over the network.
When Borg is writing to a repo on a locally mounted remote file system, e.g.
SSHFS, the Borg client only can do file system operations and has no agent
running on the remote side, so *every* operation needs to go over the network,
which is slower.
Can I backup from multiple servers into a single repository?
------------------------------------------------------------
Yes, this is *possible* from the technical standpoint, but it is
*not recommended* from the security perspective. BorgBackup is
built upon a defined :ref:`attack_model` that cannot provide its
guarantees for multiple clients using the same repository. See
:ref:`borg_security_critique` for a detailed explanation.
Also, in order for the deduplication used by Borg to work, it
needs to keep a local cache containing checksums of all file
chunks already stored in the repository. This cache is stored in
``~/.cache/borg/``. If Borg detects that a repository has been
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
repository is only modified from one place. Also keep in mind that
Borg will keep an exclusive lock on the repository while creating
or deleting archives, which may make *simultaneous* backups fail.
Can I back up to multiple, swapped backup targets?
--------------------------------------------------
It is possible to swap your backup disks if each backup medium is assigned its
own repository by creating a new one with :ref:`borg_init`.
Can I copy or synchronize my repo to another location?
------------------------------------------------------
If you want to have redundant backup repositories (preferably at separate
locations), the recommended way to do that is like this:
- ``borg init repo1``
- ``borg init repo2``
- client machine ---borg create---> repo1
- client machine ---borg create---> repo2
This will create distinct repositories (separate repo ID, separate
keys) and nothing bad happening in repo1 will influence repo2.
Some people decide against above recommendation and create identical
copies of a repo (using some copy / sync / clone tool).
While this might be better than having no redundancy at all, you have
to be very careful about how you do that and what you may / must not
do with the result (if you decide against our recommendation).
What you would get with this is:
- client machine ---borg create---> repo
- repo ---copy/sync---> copy-of-repo
There is no special borg command to do the copying, you could just
use any reliable tool that creates an identical copy (cp, rsync, rclone
might be options).
But think about whether that is really what you want. If something goes
wrong in repo, you will have the same issue in copy-of-repo.
Make sure you do the copy/sync while no backup is running, see
:ref:`borg_with-lock` about how to do that.
Also, you must not run borg against multiple instances of the same repo
(like repo and copy-of-repo) as that would create severe issues:
- Data loss: they have the same repository ID, so the borg client will
think they are identical and e.g. use the same local cache for them
(which is an issue if they happen to be not the same).
See :issue:`4272` for an example.
- Encryption security issues if you would update repo and copy-of-repo
independently, due to AES counter reuse.
See also: :ref:`faq_corrupt_repo`
"this is either an attack or unsafe" warning
--------------------------------------------
About the warning:
Cache, or information obtained from the security directory is newer than
repository - this is either an attack or unsafe (multiple repos with same ID)
"unsafe": If not following the advice from the previous section, you can easily
run into this by yourself by restoring an older copy of your repository.
"attack": maybe an attacker has replaced your repo by an older copy, trying to
trick you into AES counter reuse, trying to break your repo encryption.
Borg users have also reported that fs issues (like hw issues / I/O errors causing
the fs to become read-only) can cause this warning, see :issue:`7853`.
If you'ld decide to ignore this and accept unsafe operation for this repository,
you could delete the manifest-timestamp and the local cache:
::
borg config repo id # shows the REPO_ID
rm ~/.config/borg/security/REPO_ID/manifest-timestamp
borg delete --cache-only REPO
This is an unsafe and unsupported way to use borg, you have been warned.
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 (or rather: not-on-disk) representation of the holes
in a sparse file.
Archive creation has no special support for sparse files, holes are
backed up as (deduplicated and compressed) runs of zero bytes.
Archive extraction has optional support to extract all-zero chunks as
holes in a sparse file.
* Some filesystem specific attributes, like btrfs NOCOW, see :ref:`platforms`.
* For hardlinked symlinks, the hardlinking can not be archived (and thus,
the hardlinking will not be done at extraction time). The symlinks will
be archived and extracted as non-hardlinked symlinks, see :issue:`2379`.
Are there