Using the Stop button and “Stop after current file” (new name to go with 2.0.4.31 changes meant to allow partial backups to be recorded), it seems to stop (eventually) before full backup finishes (as it should), but running that backup again and letting it reach seeming fine completion leaves files out.
For example my whole Documents folder is not backed up with no sign of folder or files in database.
Adding a new file gets file backed up. Updating the same file seems to get it updated with new data. What’s interesting in the Verbose log is a lot of IncludingPath go by, with few IncludingChanges.
Changing my –usn-policy from required to off fixed this once. Bug seems like what USN Journal could do, e.g. if NTFS Update Sequence Number record in Duplicati advanced without files backup, which seems like the kind of situation early Stop might wind up doing. Just speculating on it though.
I normally also run with –snapshot-policy=required, but have not yet tested if USN issue requires it.
Putting out a heads-up, in case other people want to see how their Windows system behaves here.
EDIT 1:
Stopping and restarting Duplicati would not persuade it to back up the rest of my Documents folder, however configuring a source file from a previously not backed up folder did. This is likely because (IIRC) there is a hash on the configuration that’s kept in the DB, and forces a full scan if it changes.
2019-10-24 08:56:15 -04 - [Information-Duplicati.Library.Main.Operation.BackupHandler-SkipUsnForVolume]: Performing full scan for volume "C:\"
Below are views of the ChangeJournalData table before and after the config change + fixed backup:
old
ID FilesetID VolumeName JournalID NextUsn ConfigHash
1 1 C:\ 131110814199265407 72267512400 783E587246E3188CCF7092EB931721AC
2 2 C:\ 131110814199265407 72268644576 783E587246E3188CCF7092EB931721AC
3 3 C:\ 131110814199265407 72286528800 783E587246E3188CCF7092EB931721AC
4 4 C:\ 131110814199265407 72287069168 783E587246E3188CCF7092EB931721AC
5 5 C:\ 131110814199265407 72287443616 783E587246E3188CCF7092EB931721AC
6 6 C:\ 131110814199265407 72287853664 783E587246E3188CCF7092EB931721AC
7 7 C:\ 131110814199265407 72288720456 783E587246E3188CCF7092EB931721AC
8 8 C:\ 131110814199265407 72289207272 783E587246E3188CCF7092EB931721AC
9 9 C:\ 131110814199265407 72290960408 783E587246E3188CCF7092EB931721AC
10 10 C:\ 131110814199265407 72291215760 783E587246E3188CCF7092EB931721AC
new
ID FilesetID VolumeName JournalID NextUsn ConfigHash
1 1 C:\ 131110814199265407 72267512400 783E587246E3188CCF7092EB931721AC
2 2 C:\ 131110814199265407 72268644576 783E587246E3188CCF7092EB931721AC
3 3 C:\ 131110814199265407 72286528800 783E587246E3188CCF7092EB931721AC
4 4 C:\ 131110814199265407 72287069168 783E587246E3188CCF7092EB931721AC
5 5 C:\ 131110814199265407 72287443616 783E587246E3188CCF7092EB931721AC
6 6 C:\ 131110814199265407 72287853664 783E587246E3188CCF7092EB931721AC
7 7 C:\ 131110814199265407 72288720456 783E587246E3188CCF7092EB931721AC
8 8 C:\ 131110814199265407 72289207272 783E587246E3188CCF7092EB931721AC
9 9 C:\ 131110814199265407 72290960408 783E587246E3188CCF7092EB931721AC
10 10 C:\ 131110814199265407 72291304360 783E587246E3188CCF7092EB931721AC
11 11 C:\ 131110814199265407 72291304360 5D467075711206AC89D854225FF8F964
ChangeJournalData is updated after the backup itself, but what if the backup was interrupted by Stop?