mirror of
https://github.com/borgbackup/borg.git
synced 2026-09-01 14:13:19 +02:00
545183efda- quickstart: no segments in borg2 (packs/unreferenced-objects wording); backend list is file:/rest: plus sftp/s3/b2; fix the example script's exit-code handling for BORG_EXIT_CODES=modern (highest-rc-wins ranked warnings 100..127 above errors 3..99 and the rc==1 warning branch was dead) with a severity classifier; regenerate the --stats and repo-list samples from real runs; make the prose repo path match the script's rest:// URL; typos; correct the repository model description (no manifest tracking blocks). - repository-urls: use rest:// in the BORG_REPO example (ssh:// is legacy-only, as the same file says). - file-systems: rewrite for packs (chunks are grouped into pack files of up to ~50 MB; compact works at pack granularity). - resources: borg repo-delete (not "delete repo", not server-side); replace the false "single-threaded, max 100% of one core" claim with the real multi-threaded cases (zstd, blake3, pack writer). - positional-arguments: drop borg1 repo::archive wording. - config: fix the --print_config example (must precede the subcommand) and the related prose. - usage_general.rst.inc (man intro): add the archive-specification and config includes that were only added to the usage variant when the two files diverged (oversight from the #4587 split; the archive-specification include uses :start-after: to avoid a duplicate label). - fix dead links: IEC binary prefixes (wikipedia anchor moved), paperkey.html in the borg 1.x changelog. - misc: update benchmark-crud commands to borg2 (with a note that the numbers are borg1-era); add a preamble to create_chunker-params noting it predates borg2/fastcdc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
40 lines
1.8 KiB
PHP
40 lines
1.8 KiB
PHP
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.
|
|
|
|
For a local repository (or a locally mounted network filesystem) it uses the
|
|
``file:`` store (posixfs backend). For a remote repository it uses the ``rest:``
|
|
store, talking to a ``borg serve --rest`` process on the remote side (which in
|
|
turn uses borgstore there). Other backends (``sftp:``, ``rclone:``, ``s3:``/
|
|
``b2:``) do not need a filesystem on the repository side at all.
|
|
|
|
Borg does not store each chunk as a separate store object. It groups many chunks
|
|
into *pack files* of up to about 50 MB and stores each pack as one object; reading
|
|
a single chunk is a partial read at a known offset inside its pack. Thus, the
|
|
repository holds far fewer objects than it has chunks (see :ref:`packs` in the
|
|
Internals chapter for the details).
|
|
|
|
This has some pros and cons (compared to legacy Borg 1.x segment files):
|
|
|
|
Pros:
|
|
|
|
- Simplicity and better maintainability of the Borg code.
|
|
- The repository is just a key/value store, so it is easy to adapt to other kinds
|
|
of storage: borgstore's backends are quite simple to implement.
|
|
``sftp:``, ``rclone:`` and ``s3:``/``b2:`` backends already exist, others might
|
|
be easy to add.
|
|
- Parallel repository access with less locking is easier to implement.
|
|
|
|
Cons:
|
|
|
|
- Individual chunks cannot be deleted from a pack file; ``borg compact`` can only
|
|
remove a pack once none of its chunks are referenced any more, so space is not
|
|
always reclaimed immediately.
|
|
- 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.
|