Merge pull request #6659 from ThomasWaldmann/docs-fc-suffix-master

docs: mention BORG_FILES_CACHE_SUFFIX as alternative to BORG_FILES_CACHE_TTL
This commit is contained in:
TW 2022-05-07 14:39:57 +02:00 committed by GitHub
commit a3e99a2b51
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 0 deletions

View File

@ -1080,6 +1080,10 @@ will be slow because it would chunk all the files each time. If you set
BORG_FILES_CACHE_TTL to at least 26 (or maybe even a small multiple of that), BORG_FILES_CACHE_TTL to at least 26 (or maybe even a small multiple of that),
it would be much faster. it would be much faster.
Besides using a higher BORG_FILES_CACHE_TTL (which also increases memory usage),
there is also BORG_FILES_CACHE_SUFFIX which can be used to have separate (smaller)
files caches for each backup set instead of the default one (big) unified files cache.
Another possible reason is that files don't always have the same path, for Another possible reason is that files don't always have the same path, for
example if you mount a filesystem without stable mount points for each backup example if you mount a filesystem without stable mount points for each backup
or if you are running the backup from a filesystem snapshot whose name is not or if you are running the backup from a filesystem snapshot whose name is not