Я использую Postgres 9.6 и делаю резервное копирование, просто останавливая кластер и используя rsync на уровне файлов. Однажды я понял, что некоторые старые, уже зарезервированные файлы для таблиц по-прежнему имеют тот же размер и временную метку, что и их аналог в исходном коде, но rsync пытается их сохранить, поскольку содержимое этих файлов не изменилось. Важно отметить, что в отношении отметок времени в источнике файлы не менялись ни днями, ни даже неделями. rsync использует контрольные суммы и вычисляет MD5-хэши для рассматриваемых файлов, также выявляет различные хэши. Ниже приведен один пример:
Резервное копирование:
a1171645dc187c498ce05a25b0e5157f 2613.13
-rw------- 12 109 119 1073741824 May 21 04:58 2613.13
Производство:
f02c1c2724714af2c5c08f8b67ab0f11 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
Точно такой же файл относительно размера и временной метки, но на самом деле другой контент. После использования rsync с контрольными суммами файл в резервной копии по-прежнему имеет тот же размер и временную отметку, но новое содержимое, поскольку на этот раз вычисленный хэш такой же, как и в рабочей среде.
Файл принадлежит pg_largeobject и эта таблица содержит много данных, отсюда и названные суффиксы. Большинство из этих файлов в последовательности имеют старые временные метки, как указано выше, более нескольких дней без какой-либо записи, и не все резервные копии и имеют такой же хэш MD5, как в моей резервной копии. Только несколько файлов время от времени отличаются, как в примере.
Из следующих очень старых файлов данных, в основном неизменных по дням / неделям, например, 2613.13 были переданы из-за разных контрольных сумм, а 2613.10 нет:
-rw------- 1 postgres postgres 1073741824 Jun 4 04:40 2613
-rw------- 1 postgres postgres 1073741824 Mai 21 04:42 2613.1
-rw------- 1 postgres postgres 1073741824 Mai 21 04:56 2613.10
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.11
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.12
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:59 2613.14
-rw------- 1 postgres postgres 1073741824 Mai 28 04:40 2613.15
-rw------- 1 postgres postgres 686645248 Jun 4 04:42 2613.16
-rw------- 1 postgres postgres 1073741824 Mai 21 04:44 2613.2
-rw------- 1 postgres postgres 1073741824 Mai 21 04:46 2613.3
-rw------- 1 postgres postgres 1073741824 Mai 21 04:47 2613.4
-rw------- 1 postgres postgres 1073741824 Mai 21 04:49 2613.5
-rw------- 1 postgres postgres 1073741824 Mai 21 04:50 2613.6
-rw------- 1 postgres postgres 1073741824 Mai 21 04:52 2613.7
-rw------- 1 postgres postgres 1073741824 Mai 21 04:53 2613.8
-rw------- 1 postgres postgres 1073741824 Jun 4 04:40 2613.9
-rw------- 1 postgres postgres 4407296 Jun 4 04:42 2613_fsm
-rw------- 1 postgres postgres 548864 Jun 4 04:42 2613_vm
Будучи pg_largeobject и поскольку мы на самом деле удаляем большие объекты из базы данных время от времени, повторное использование существующих файлов вполне приемлемо для Postgres и, как и ожидалось. Но все мои тесты показали, что во время записи метка времени этих файлов фактически обновляется, а не сохраняется или сбрасывается в прошлое. Используемая нами файловая система - ext4, поэтому вообще не должно быть проблем с метками времени.
И это то, что заставляет меня задуматься: если Postgres не сбрасывает метки времени в прошлое или почему-то их замораживает, это похоже на повреждение данных в моих резервных копиях.
Итак, есть ли такая функциональность в Postgres, записывающая данные без изменения временных меток файла в файловой системе?
Из-за отсутствия ответа я также задал вопрос в списке рассылки Postgres .