Merge pull request #4715 from ThomasWaldmann/forward-port-4583

timestamps in the files cache are now usually ctime, fixes #4583
This commit is contained in:
TW 2019-08-09 22:00:46 +02:00 committed by GitHub
commit 0db031ac4a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 7 deletions

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 rather get a partial file extracted than nothing). You do **not** want to give
that option under any normal circumstances. 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. 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`. 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 The files cache is used to determine whether Borg already
"knows" / has backed up a file and if so, to skip the file from "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 chunking. It does intentionally *not* contain files that have a timestamp
time (mtime) same as the newest mtime in the created archive. 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 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 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 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 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 the snapshot would not be contained in the next backup as Borg would
think the file is unchanged. 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. data chunks.
If you want to avoid unnecessary chunking, just create or touch a small or 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 not your 50GB VM disk image) and, if you do snapshots, do the snapshot after
that. 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 those files are reported as being added when, really, chunks are
already used. 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: .. _always_chunking:
It always chunks all my files, even unchanged ones! 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 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 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 stored in the files cache). If the values are the same, the file is assumed