mirror of https://github.com/borgbackup/borg.git
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:
commit
0db031ac4a
17
docs/faq.rst
17
docs/faq.rst
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue