mirror
/
borg
mirror of https://github.com/borgbackup/borg.git
1
0
Fork 0
Code Issues Releases Wiki Activity

timestamps in the files cache are now usually ctime, fixes #4583

This commit is contained in:
Thomas Waldmann 2019-08-09 21:11:44 +02:00
parent e299ad824c
commit 8622014188
1 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/faq.rst
View File

@ -151,7 +151,7 @@ really desperate (e.g. if you have no completed backup of that file and you'ld
rather get a partial file extracted than nothing). You do **not** want to give
that option under any normal circumstances.
Note that checkpoints inside files are created only since version 1.1,
Note that checkpoints inside files are created only since version 1.1,
make sure you have an up-to-date version of borgbackup if you want to continue instead of retransferring a huge file.
In some cases, there is only an outdated version shipped with your distribution (e.g. Debian). See :ref:`installation`.
@ -601,15 +601,15 @@ I am seeing 'A' (added) status for an unchanged file!?
The files cache is used to determine whether Borg already
"knows" / has backed up a file and if so, to skip the file from
chunking. It does intentionally *not* contain files that have a modification
time (mtime) same as the newest mtime in the created archive.
chunking. It does intentionally *not* contain files that have a timestamp
same as the newest timestamp in the created archive.
So, if you see an 'A' status for unchanged file(s), they are likely the files
with the most recent mtime in that archive.
with the most recent timestamp in that archive.
This is expected: it is to avoid data loss with files that are backed up from
a snapshot and that are immediately changed after the snapshot (but within
mtime granularity time, so the mtime would not change). Without the code that
timestamp granularity time, so the timestamp would not change). Without the code that
removes these files from the files cache, the change that happened right after
the snapshot would not be contained in the next backup as Borg would
think the file is unchanged.
@ -620,7 +620,7 @@ mentioned rare condition), it will just re-use them as usual and not store new
data chunks.
If you want to avoid unnecessary chunking, just create or touch a small or
empty file in your backup source file set (so that one has the latest mtime,
empty file in your backup source file set (so that one has the latest timestamp,
not your 50GB VM disk image) and, if you do snapshots, do the snapshot after
that.
@ -628,13 +628,16 @@ Since only the files cache is used in the display of files status,
those files are reported as being added when, really, chunks are
already used.
By default, ctime (change time) is used for the timestamps to have a rather
safe change detection (see also the --files-cache option).
.. _always_chunking:
It always chunks all my files, even unchanged ones!
---------------------------------------------------
Borg maintains a files cache where it remembers the mtime, size and
Borg maintains a files cache where it remembers the timestamp, size and
inode of files. When Borg does a new backup and starts processing a
file, it first looks whether the file has changed (compared to the values
stored in the files cache). If the values are the same, the file is assumed