TL; DR

После обновления моего пула ZFS с 0.7.x до 0.8.3 (и Ubuntu с 18.04.x ​​до 20.04.1) моя резервная копия данных Nextcloud (почти) всегда полная резервная копия. Перед обновлением все было хорошо, плюс мой другой, системный rpool, ведет себя так, как задумано.

Реальная история

У меня настроено две резервные копии TAR. Резервное копирование системы, которое было и было хорошо, и резервное копирование данных Nextcloud, которое тоже было хорошо, но уже не так. Более года он отлично работал на ZFS 0.7.x и Ubuntu 18.04.x. Некоторое время назад я перешел на Ubuntu 20.04, а затем на 20.04.1, и с момента первого обновления резервная копия Nextcloud была (почти) всегда полной резервной копией. Бывает, что 1 из 10 делает инкрементное резервное копирование, как задумано, но, к сожалению, это больше похоже на сбой, чем на правило.

Juice

В моей резервной копии нет ничего особенного:

tar -cpz \
    --listed-incremental="$backupIncrementalMetadataFullFileName" \
    --exclude="$backupLocation" \
    --exclude="*RychuSrv*Backup*.*" \
    "/srv/nextcloud/${nextcloudFolderName}" \
        | tee "$tarBackupFullFileName" \
        | gpg [censored]

ZFS происходит?

Я обращаю внимание на ZFS, потому что ... что еще? :) Но я не могу понять, из-за чего это произошло. Я попытался сравнить мое хорошее поведение rpool и Nextcloud, и, за исключением очевидных различий, таких как даты или руководства, я не нашел ничего значимого.Свойства, которые имеют разные значения:

• devices
• createtxg
• autotrim ( rpool is SSD)
• canmount (резервная копия имеет на и rpool имеет noauto )

Другие функции / свойства, которые, как я знаю, могут повлиять на проблему: atime и в реальном времени , и оба на обоих пулы: на .

Как выглядят файлы

Таким образом, резервные копии создаются в основном изображениями и видеофайлами в папках, большинство из которых не менялись в течение очень долгого времени. Например:

# ls -1l . | tail -n 500 | head -n 10
-rw-r--r-- 1 www-data www-data    2113359 Jan  5  2020 IMG_20200105_172639.jpg
-rw-r--r-- 1 www-data www-data    2029782 Jan  5  2020 IMG_20200105_172641.jpg
-rw-r--r-- 1 www-data www-data    2374428 Jan  5  2020 IMG_20200105_172652.jpg
-rw-r--r-- 1 www-data www-data    2523738 Jan  5  2020 IMG_20200105_172654.jpg
-rw-r--r-- 1 www-data www-data    3405077 Jan  6  2020 IMG_20200106_083530.jpg
-rw-r--r-- 1 www-data www-data    1989491 Jan  6  2020 IMG_20200106_183744.jpg
-rw-r--r-- 1 www-data www-data    2220897 Jan 11  2020 IMG_20200111_131056.jpg
-rw-r--r-- 1 www-data www-data    2850718 Jan 11  2020 IMG_20200111_132928.jpg
-rw-r--r-- 1 www-data www-data    2095188 Jan 11  2020 IMG_20200111_132956.jpg
-rw-r--r-- 1 www-data www-data    2312352 Jan 11  2020 IMG_20200111_133414.jpg

# stat IMG_20200111_131056.jpg
  File: IMG_20200111_131056.jpg
  Size: 2220897         Blocks: 4369       IO Block: 131072 regular file
Device: 43h/67d Inode: 328087      Links: 1
Access: (0644/-rw-r--r--)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2020-08-05 00:16:30.136312800 +0200
Modify: 2020-01-11 13:10:57.000000000 +0100
Change: 2020-01-13 14:36:14.531413322 +0100
 Birth: -

Вы можете видеть, что доступ к файлу был осуществлен сразу после полуночи, это означает, что сценарий резервного копирования перенес его в резервную копию.

Почему? Файл был изменен более 6 месяцев назад!

PS. Я только что заметил, что время доступа имеет другой часовой пояс. Разве это не странно?