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>
81 lines
3.4 KiB
HTML
81 lines
3.4 KiB
HTML
Resource Usage
|
|
~~~~~~~~~~~~~~
|
|
|
|
Borg might use significant resources depending on the size of the data set it is dealing with.
|
|
|
|
If you use Borg in a client/server way (with an SSH repository),
|
|
the resource usage occurs partly on the client and partly on the
|
|
server.
|
|
|
|
If you use Borg as a single process (with a filesystem repository),
|
|
all resource usage occurs in that one process, so add up client and
|
|
server to get the approximate resource usage.
|
|
|
|
CPU client:
|
|
- **borg create:** chunking, hashing, compression, encryption (high CPU usage)
|
|
- **chunks index rebuild:** quite heavy on CPU, doing lots of hash table operations
|
|
- **borg extract:** decryption, decompression (medium to high CPU usage)
|
|
- **borg prune/borg delete archive:** quick, low CPU usage
|
|
- **borg repo-delete:** low CPU usage, it just removes the repository's objects
|
|
- **borg compact:** medium CPU usage
|
|
- **borg check:** medium CPU usage, but depends on options given
|
|
|
|
Most of Borg is single-threaded, but some parts do use more than one CPU core:
|
|
|
|
- zstd compresses a chunk multi-threaded by default (only for chunks of at
|
|
least 768 KiB, using at most 4 threads); see ``BORG_ZSTD_MT_WORKERS``.
|
|
- the BLAKE3 based id-hash / MAC modes hash multi-threaded for inputs from
|
|
256 KiB on; see ``BORG_BLAKE3_MT_THRESHOLD``.
|
|
- ``borg create`` hands each finished pack file to a background thread, so
|
|
hashing and storing a pack overlaps with processing the next one.
|
|
|
|
Especially higher zlib and lzma compression levels use significant amounts
|
|
of CPU cycles. Crypto might be cheap on the CPU (if hardware-accelerated) or
|
|
expensive (if not).
|
|
|
|
CPU server:
|
|
It usually does not need much CPU; it just deals with the key/value store
|
|
(repository).
|
|
|
|
borg check: the repository check computes the checksums of all chunks
|
|
(medium CPU usage)
|
|
borg compact: low to medium CPU usage
|
|
|
|
CPU (only for client/server operation):
|
|
When using Borg in a client/server way with an ssh-type repository, the SSH
|
|
processes used for the transport layer will need some CPU on the client and
|
|
on the server due to the crypto they are doing — especially if you are pumping
|
|
large amounts of data.
|
|
|
|
Memory (RAM) client:
|
|
The chunks index and the files index are read into memory for performance
|
|
reasons. Might need large amounts of memory (see below).
|
|
Compression, especially with high compression levels, might need substantial
|
|
amounts of memory.
|
|
|
|
Memory (RAM) server:
|
|
Usually rather low memory needs, much less than the client.
|
|
|
|
Chunks index (client only):
|
|
Proportional to the number of data chunks in your repo. Lots of chunks
|
|
in your repo imply a big chunks index.
|
|
It is possible to tweak the chunker parameters (see create options).
|
|
|
|
Files index (client only):
|
|
Proportional to the number of files in your last backups. Can be switched
|
|
off (see create options), but the next backup might be much slower if you do.
|
|
The speed benefit of using the files cache is proportional to file size.
|
|
|
|
Temporary files (client):
|
|
TODO
|
|
|
|
Temporary files (server):
|
|
TODO
|
|
|
|
Cache files (client only):
|
|
Contains the files cache, which might become quite large depending on the
|
|
amount and size of files.
|
|
|
|
Network (only for client/server operation):
|
|
If your repository is remote, all deduplicated (and optionally compressed/
|
|
encrypted) data has to go over the network connection.
|