| 12345678910111213141516171819202122232425262728293031323334353637 |
- File systems
- ~~~~~~~~~~~~
- We recommend using a reliable, scalable journaling filesystem for the
- repository, e.g., zfs, btrfs, ext4, apfs.
- Borg now uses the ``borgstore`` package to implement the key/value store it
- uses for the repository.
- It currently uses the ``file:`` store (posixfs backend) either with a local
- directory or via SSH and a remote ``borg serve`` agent using borgstore on the
- remote side.
- This means that it will store each chunk into a separate filesystem file
- (for more details, see the ``borgstore`` project).
- This has some pros and cons (compared to legacy Borg 1.x segment files):
- Pros:
- - Simplicity and better maintainability of the Borg code.
- - Sometimes faster, less I/O, better scalability: e.g., borg compact can just
- remove unused chunks by deleting a single file and does not need to read
- and rewrite segment files to free space.
- - In the future, easier to adapt to other kinds of storage:
- borgstore's backends are quite simple to implement.
- ``sftp:`` and ``rclone:`` backends already exist, others might be easy to add.
- - Parallel repository access with less locking is easier to implement.
- Cons:
- - The repository filesystem will have to deal with a large number of files (there
- are provisions in borgstore against having too many files in a single directory
- by using a nested directory structure).
- - Greater filesystem space overhead (depends on the allocation block size — modern
- filesystems like zfs are rather clever here, using a variable block size).
- - Sometimes slower, due to less sequential and more random access operations.
|
