Restic: Restic использует mtime для обнаружения изменений файлов, которые могут пропустить изменения.

Использование mtime вызывает еще одну проблему - изменения только в метаданных, таких как владелец, группа, режимы, списки управления доступом POSIX и любые расширенные атрибуты, не обнаруживаются вообще.

Вариант -f помогает, но для резервного копирования огромной файловой системы требуется много времени, так как это просто эквивалентно первоначальному резервному копированию - например, в моем случае (около 35 ГБ данных, более 600 тыс. Файлов) требуется ок. 1,5 часа для создания первой резервной копии, затем менее 10 млн для каждого снимка, но с -f всегда выполняется более 1 часа.

Использование mtime вызывает еще одну проблему - изменения только в метаданных, таких как владелец, группа, режимы, списки управления доступом POSIX и любые расширенные атрибуты, не обнаруживаются вообще.

Хм, что ты имеешь в виду? Все упомянутые до сих пор проверки (mtime, ctime, реализованные в # 2212) используются только для определения того, нужно ли перечитывать файл. Метаданные, включая ACL, всегда загружаются и записываются в репо. Если он не изменился с момента последнего резервного копирования, дедупликация restic позаботится о том, чтобы оно больше не сохранялось. Если что-то изменилось, метаданные сохраняются в репо.

Я что-нибудь упускаю?

@ fd0 Я имею в виду, что если были изменены только метаданные, mtime вообще не изменяется, поэтому любые изменения только в метаданных не будут выполняться для резервного копирования, поскольку файл вообще не распознается как измененный, по крайней мере, так было в 0.9.4 и все еще так в 0.9.5 (только что пробовал). Я записал сеанс, который демонстрирует это (снова используя chown и резервную копию).

После реализации # 2212 он должен работать (я надеюсь), но в текущих выпущенных версиях это не так, если не используется --force (но принудительное повторное чтение всего слишком дорого).

@aldem ой, теперь я понимаю и могу воспроизвести это. Я думаю, что это (отдельная) ошибка (и регресс) нового кода архиватора, представленного в версии 0.9.0. Я займусь расследованием ...

Это регресс, корректно работает с 0.8.3. Открою новую проблему и исправлю.

Это отслеживается как # 2249.

@ fd0 Спасибо, это был настоящий фурор.

Я нашел этот билет, а затем номер 2212, поэтому я подумал, что это еще не реализовано, поэтому я не отправил отчет об ошибке.

Пожалуйста, извините, но не следует ли нам больше предупреждать пользователей об этой проблеме? Что-то вроде «ВНИМАНИЕ: во всех ваших резервных копиях, сделанных с помощью restic <= 0.9.5, могут отсутствовать измененные файлы!».

Я узнал об этом только после того, как меня сильно укусили (это

Я думаю, что серьезность этого выходит за рамки того, что просто сводит с ума кого-то, кто проверяет все (например, контрольную сумму SHA для восстановленных файлов), как я, поскольку изменения, которые должны были быть зарезервированы, пропускаются - если кому-то нужно восстановить один из этих файлов из резервной копии (например, ошибка оператора, аварийное восстановление и т. д.) он / она без какого-либо предупреждения просто получит более старый, устаревший файл: - / и в таком сценарии, то есть после потери исходного файла, он будет потерян навсегда: там очевидно, что нет способа восстановить его из резервной копии restic: frowning:

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

Мы можем поговорить об этом немного подробнее, пожалуйста?

Разве это не стандартное поведение инструментов резервного копирования Unix - использовать mtime для обнаружения измененных файлов?

Очевидно, что если вы измените данные файла A, а затем установите для него значение mtime, которое было до изменения данных, файл останется неизменным. Это похоже на классический случай: «Доктор, мне больно, когда я ткну себя в глаз».

Также очевидно, что в дикой природе существует большое количество разнообразных инструментов, и некоторые из них могут делать то же самое. Итак, действительно, Restic должен иметь возможность учитывать ctime или другие временные метки, чтобы определять, изменился ли файл. Иметь такую ​​возможность, несомненно, хорошо.

Но мне кажется фикцией изменение значения по умолчанию. AFAIK, это неожиданное, нестандартное поведение для средства резервного копирования Unix, и, как отмечено в # 2495, изменение значения по умолчанию имеет значительные нежелательные последствия.

Кроме того, это изменение было внесено в выпуск "Z" (как и в версии XYZ в стиле SemVer), который должен быть зарезервирован для исправления ошибок, а не для изменения поведения по умолчанию. # 2495 - лишь один из примеров пользователей Restic с огромным объемом данных (14 ТБ в этом случае). Я думаю, что пользователи Restic должны быть в состоянии ожидать, что обновление с 0.9.x до 0.9.y не изменит никаких действий, кроме исправления ошибок.

И эта проблема почти наверняка НЕ ​​была ошибкой, потому что любая программа, которая намеренно изменяет mtime файлов, данные которых изменились на более раннюю временную метку, почти наверняка делает Неправильную вещь и должна ожидать, что это повлияет на инструменты резервного копирования.

Итак, я думаю, что поведение по умолчанию следует изменить обратно на использование mtime, что кажется стандартным для инструментов резервного копирования Unix.

Если я ошибаюсь в том, что mtime является стандартом для инструментов резервного копирования Unix, возможно, стоит провести опрос.

Спасибо.

SemVer говорит:

1. Основная нулевая версия (0.yz) предназначена для начальной разработки. Все может измениться в любой момент. Публичный API НЕ СЛЕДУЕТ считать стабильным.

@alphapapa На самом деле, некоторые "стандартные" инструменты резервного копирования * ix, такие как tar (хотя официального стандарта, если быть точным), проверяют ctime, поскольку без проверки ctime было бы невозможно обнаружить изменения, связанные только с метаданными (право собственности, режимы и т. д. ).

@alphapapa написал:

Разве это не стандартное поведение инструментов резервного копирования Unix - использовать mtime для обнаружения измененных файлов?

Нет, все, что мне известно о правильном резервном копировании, использует ctime. mtime бесполезен для резервного копирования, так как он может быть установлен на произвольное значение, что часто бывает. Простая распаковка tar-файла приведет к появлению файлов с mtime, установленным на то, что было раньше.

Резервные копии , сделанные Rsync стиль делают использовать время изменения (но не против прироста, просто чтобы увидеть , если он отличается), и Rsync делает несоосность файлы , которые были изменены.

@alphapapa Я считаю это исправлением ошибки, потому что с mtime restic может потерять данные (файл был изменен, но mtime был сброшен) и не получить изменения, связанные только с метаданными. И то, и другое ИМХО очень нежелательно. Я не ожидал, что будет так много случаев, когда restic перечитывает данные. Хммм.

Если я ошибаюсь в том, что mtime является стандартом для инструментов резервного копирования Unix, возможно, стоит провести опрос.

По крайней мере, borg обнаруживает изменения на основе ctime , size и inode по умолчанию: https://borgbackup.readthedocs.io/en/stable/usage /create.html

Здесь было сделано несколько утверждений, которые не обязательно верны, но и не обязательно ошибочны, и я долго размышлял, стоит ли им оспаривать ...

Первое, что я хотел бы сделать, это то, что ни ctime, ни mtime не могут быть надежными методами определения того, произошло ли изменение. Это было особенно верно в прошлом, когда эти временные метки имели вторую степень детализации (или, возможно, хуже, хотя я, к счастью, никогда с этим не сталкивался). Это означает, что это влияет на многие инструменты, помимо инструментов резервного копирования, включая давно используемую команду make для создания программного обеспечения. Это улучшилось благодаря тому, что файловые системы теперь имеют микросекундную или лучшую степень детализации, но я думаю, что совершенно неверно полагать, что одна только временная метка может когда-либо определить, действительно ли произошло изменение или нет. Всегда будут крайние случаи, и лучшее, что вы можете сделать, это попытаться уменьшить число крайних случаев, хотя это часто приводит к снижению производительности.

Если вы действительно хотите знать, изменилось ли содержимое, вам нужно проверить содержимое. Это относится как к данным, так и к метаданным. Вот почему такие команды, как «rsync», имели возможность проверять контент с самого начала, насколько я себя помню. Всегда есть выбор: нельзя ли доверять меткам времени, и в этом случае следует провести полное сравнение всего содержимого, или можно доверять меткам времени, и в этом случае определенные операции можно пропустить для оптимизации процесса.

ctime check - пример такого компромисса. Добавляя ctime в список проверок, вы значительно снижаете и без того низкую вероятность отказа, но цена заключается в том, что вы внезапно добавляете количество ложных срабатываний. ctime update не означает, что содержимое было изменено или какие-либо данные, записанные в резервной копии, были изменены. Это только указывает на то, что «что-то в индексном дескрипторе изменилось».

Основная проблема, с которой я сталкиваюсь с ctime, заключается в том, что ctime проверяет данные, которые могут быть запрошены полностью по низкой цене, и это то, что делает rsync. Я имею в виду, что ctime будет обновляться, если метаданные изменятся, но проверка метаданных напрямую на наличие изменений всегда лучше, чем проверка ctime. Скорее всего, я никогда не буду писать код, который говорит: «Если ctime не обновился, пропустите проверку владельца, группы, размера или номера inode». Вызов stat () возвращает всю эту информацию, и она легко доступна. Проверка метаданных примерно равна стоимости и более надежна, чем проверка того, обновилась ли метка времени для метаданных. Итак, я действительно не считаю обновление ctime доказательством чего-либо, кроме того, что система, пометившая индексный дескриптор, была обновлена, и если мы уже проверяем метаданные, которые нас интересуют, это не совсем ценная информация.

Единственным исключением, по-видимому, является случай команды типа «restore», такой как вышеупомянутый tar, восстанавливающей mtime в прошлое, которая имеет каскадный эффект, заставляющий резервную копию видеть более старую временную метку. По моему опыту, я не обнаружил, что это так проблематично, как описано. Отметка времени обновляется после заполнения файла данными, и при любом сравнении с отметкой времени следует использовать "не равно", а не "больше чем" или "меньше чем", поэтому я на самом деле не вижу упомянутый ранее случай проблемы как случай реальное беспокойство. На самом деле, я склонен утверждать обратное - если данные были восстановлены, возможно, их следует пропустить. Хотя, это должно быть явное решение человека, производящего манипуляции.

Я также думаю, что стоит упомянуть, что существуют инструменты «восстановления», которые могут восстанавливать «ctime», а также «mtime». Например, в нескольких моих случаях использования - мы активно используем моментальные снимки тонких томов LVM, возможно, с координацией приложений для «стабилизации» данных (как правило, сбрасываем их на диск и приостанавливаем некоторые типы обновлений), монтируем определенные моментальные снимки на «резервная» точка монтирования, а затем запустите Commvault (текущая система) для «резервной» точки монтирования. Мы хотим переключить это на Restic. Этот дополнительный контекст призван объяснить, что использование ctime и номера inode - это аспекты файловой системы POSIX, которые не обязательно сохраняются или интерпретируются в соответствии с возлагаемыми на них ожиданиями. Другие системы будут включать технологии репликации. В основном поэтому restic имеет параметр «--ignore-inode», потому что часто эти серверные системы даже не претендуют на соблюдение типа применяемой интерпретации, и это делает любые проверки ctime недействительными.

Я думаю, что есть законные причины для мониторинга ctime и законные причины игнорировать ctime. Это не тот случай, когда один лагерь определенно правильный, а другой - неверный. Это тот случай, когда важно понимать, как создаются ваши данные и как они обновляются, чтобы понять, каков правильный компромисс между эффективными и надежными резервными копиями.

Пока что в моих случаях "--ignore-inode" удовлетворяет моим требованиям. В реальной жизни мы, вероятно, будем использовать «--ignore-inode» в большинстве, если не во всех реальных приложениях Restic. Нам не нужно поведение проверки ctime. Я не верю, что rsync пропускает столько случаев, сколько предлагают люди, и не верю, что ctime решает эту проблему на 100%. Я считаю, что это крайне консервативный взгляд на мир. Это консервативное мнение может быть верным, если вы не понимаете, как данные создаются и обновляются, или если вы считаете, что затраты на производительность заслуживают дополнительной проверки. На мой взгляд, что касается наших реальных производственных данных, я не согласен с тем, что стоимость производительности стоит дополнительной проверки, и я посоветую, чтобы "--ignore-inode" был тщательно рассмотрен и рекомендован во всех случаях, если вы не также хотят отслеживать особые исключительные случаи, о которых предупреждали определенные люди.

@MarkMielke

Проверка метаданных примерно равна стоимости и более надежна, чем проверка того, обновилась ли метка времени для метаданных.

Вы забыли о списках ACL POSIX и расширенных атрибутах в целом - это не возвращается вызовом stat (), но даже вся информация об индексных дескрипторах, возвращаемая stat (), по-прежнему требует дополнительных сравнений, так что это только относительно "низкая стоимость" (она имеет быть проанализированы / десериализованы и сравнены один за другим). Умножьте это на миллионы файлов и получите картину ...

Что касается разрешения по времени - да, в некоторых крайних случаях (не) изменение ctime (на древних файловых системах, которым не хватает субсекундного разрешения) может пропустить фактические обновления, но очень маловероятно, даже если резервное копирование выполняется один раз в минуту, вероятность того, что конкретное изменение будет одна и та же секунда только во время предыдущего резервного копирования, а не между ними, довольно низки, возможно, в очень сильно загруженных системах (но если система сильно загружена, ваша резервная копия для сравнения содержимого, скорее всего, полностью убьет ее производительность).

Я не верю, что rsync пропускает столько случаев, сколько предлагают люди, и не верю, что ctime решает эту проблему на 100%.

Я не могу говорить за всех, но за более чем 15 лет использования rsync с проверками ctime + mtime у меня никогда не было проблем с пропущенными измененными (мета) данными (а это петабайты данных и миллиарды синхронизированных файлов), в то время как с restic (когда ctime игнорировался) я заметил проблему почти мгновенно (когда были пропущены изменения владельца / режима), а обходной путь (всегда сравнивая контент) значительно увеличил время ввода-вывода и резервного копирования даже при резервном копировании с относительно небольшим объемом.

Вам повезло, если ваша резервная копия длится менее одного часа (при постоянном сравнении содержимого), но если для этого требуется 8-16 часов, и вам нужно делать это каждый день хотя бы один раз, вы быстро обнаружите, что это огромный стресс. в системе (= все работает очень медленно), в то время как ctime (особенно с микро- или наносекундным разрешением, присутствующим в современных файловых системах) почти полностью исключает возможность пропустить изменение, по крайней мере, в метаданных, и я не знаю ни одного метода ( по крайней мере, в Linux), который может напрямую управлять ctime (конечно, исключая создание образа диска), что делает его неплохим индикатором изменений метаданных / данных.

Основное преимущество заключается в том, что в большинстве практических случаев ctime помогает _ избежать_ сравнения метаданных или содержимого, тем самым значительно (на порядки) сокращая время резервного копирования.

Да, я согласен с тем, что должны быть варианты для настройки рестического поведения (возможно, даже расширение их для использования различных методов на основе путей / шаблонов), но в любом случае «по умолчанию» (tar / rsync-like) должен быть основан на ctime + mtime, и я считаю, что он работает как положено «из коробки» для 99% пользователей.

Единственным исключением, по-видимому, является случай команды типа «restore», такой как вышеупомянутый tar, восстанавливающей mtime в прошлое, которая имеет каскадный эффект, заставляющий резервную копию видеть более старую временную метку. По моему опыту, я не обнаружил, что это так проблематично, как описано.

Я сталкивался с этим много раз. Хотя с git это кажется менее распространенным, я часто распаковывал архивы файлов.

Что касается сбоев rsync. Чтобы уточнить, я не верю, что rsync когда-либо использует ctime. Он сравнивает только два дерева, и, поскольку ctime не может быть установлен, он не может установить то же значение, что и исходный файл. Он сравнивает только mtime и, возможно, другие атрибуты. У меня он потерпел неудачу, когда пакет debian заменил сжатый файл повторным сжатием того же файла. Для mtime было установлено время исходного файла, и он повторно сжался до того же размера. Но поскольку заголовок gzip имеет отметку времени, содержимое было другим. В данном случае это не имело большого значения, кроме случаев, когда я попросил dpkg проверить содержимое установленных пакетов, и хеш файла был неправильным.

Я принимаю ваше мнение о том, что управление доступом и расширенные атрибуты обходятся дороже, если запросить только lstat (). Однако я хотел бы отметить, что это случай «лучше быть в безопасности» по сравнению с «производительностью», и вы выбираете производительность. Я имею в виду, что когда я использую rsync и указываю флаги -avHAXS которыми я так хорошо знаком с набором текста, я решаю оплатить эту стоимость, в то время как вы предпочитаете не делать этого. Вы также согласились с тем, что в прошлом ctime со второй степенью детализации имела уровень риска, но вы готовы определить риск как довольно низкий. Итак, наши определения комфорта гораздо более серые, чем выровненные или полярные противоположности. :-)

Я не могу говорить за всех, но за более чем 15 лет использования rsync с проверками ctime + mtime у меня никогда не было проблем с пропущенными измененными (мета) данными (а это петабайты данных и миллиарды синхронизированных файлов),. ..

Интересно, что вы так говорите, поскольку мой опыт такой же ... с одним исключением. Rsync не использует ctime. Я был почти уверен, что это не так, но я только что проверил источник, чтобы быть абсолютно уверенным, и это не так. Нет никаких упоминаний о st_ctim или st_ctime, которые являются полями, которые извлекаются из lstat () для определения ctime файла. Есть несколько упоминаний st_mtime, которые втягиваются в структуру данных file-> modtime, где в файловой структуре также нет места для ctime.

Итак, это заставляет меня задуматься по этому поводу:

... в то время как с restic (когда ctime игнорировалось) я заметил проблему почти мгновенно (когда были пропущены изменения владельца / режима), и обходной путь (всегда сравнивая контент) значительно увеличил время ввода-вывода и резервного копирования даже при резервном копировании с относительно небольшим объемом .

Кажется, это настоящая проблема, с которой вы столкнулись! Это заставляет меня подозревать, что вы имели дело с условиями гонки или какой-то другой проблемой. У rsync также есть условия гонки, но именно поэтому вы обычно запускаете его более одного раза для сбора обновлений, «поскольку» он просканировал эту часть каталога, или, если вы чувствуете себя особенно педантично, как я, вы делаете снимки файловой системы, и используйте rsync или restic для моментального снимка, чтобы обеспечить согласованность файловой системы.

Rsync не использует ctime.

Что ж, тогда я предполагал, что rsync использует ctime для обнаружения изменений метаданных, поскольку они всегда собирались, хотя остальное наверняка было сделано mtime (в моих наборах данных нет ничего, что преднамеренно манипулирует mtime, оно обновляется только по содержимому обновления).

Но даже в том случае, если мы прибегаем только к сравнению метаданных (при условии, что mtime надежно обнаруживает изменения содержимого), экономия довольно велика. Я действительно не мог позволить себе ждать 8 часов каждый раз, когда необходимо выполнить резервное копирование, и вы правы - я готов принять на себя риск, особенно сейчас, когда временное разрешение находится в масштабе наносекунды.

Честно говоря, я даже представить себе не мог, что два изменения будут внесены за одну наносекунду даже на RAM-диск, учитывая все эти накладные расходы на обработку ввода-вывода (системные вызовы, переключение контекста и т. Д.).

Это заставляет меня подозревать, что вы имели дело с условиями гонки или какой-то другой проблемой.

Никаких условий гонки, это было действительно просто - резервная копия была сделана один раз, затем несколько файлов получили изменения режима / ACL (сделанные через несколько минут после резервного копирования, так что определенно нет проблем с разрешением [см]), и это не произвело никакой активности на следующем резервное копирование запускается через некоторое время. Однако это оказалось ошибкой в ​​restic, поскольку он не сравнивал метаданные и не проверял ctime.

Rsync не использует ctime.

Rsync не использует ctime, потому что не может. Речь идет о синхронизации двух каталогов. Поскольку ctime не может быть установлен, нет смысла сравнивать его с чем-либо.

Это сильно отличается от чего-то вроде restic (или почти любого другого решения для резервного копирования), где хранится ctime. В этом случае он заставляет сравнить ctime с тем, что хранится в резервной копии. Я бы пошел так далеко, чтобы утверждать, что сравнение ctime - это единственный способ правильно создать резервную копию всего, и именно поэтому, насколько я могу судить, каждая система резервного копирования (кроме rsync, которую я бы на самом деле не называл резервной копией) использует ctime, чтобы определить, что нужно резервировать.

Rsync - это совсем другой инструмент, чем Restic.

Никаких условий гонки, это было действительно просто - резервная копия была сделана один раз, затем несколько файлов получили изменения режима / ACL (сделанные через несколько минут после резервного копирования, так что определенно нет проблем с разрешением [см]), и это не произвело никакой активности на следующем резервное копирование запускается через некоторое время. Однако это оказалось ошибкой в ​​restic, поскольку он не сравнивал метаданные и не проверял ctime.

Да, это огромная ошибка. Сам по себе, без каких-либо других факторов. Он должен проверять либо метаданные, либо, я полагаю, хотя бы метку времени метаданных (= ctime). :-)

... и именно поэтому, насколько я могу судить, каждая система резервного копирования (кроме rsync, которую я бы не стал называть резервной копией) использует ctime для определения того, что нужно резервировать.

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

Причина, по которой я здесь, заключается в том, что я считаю, что Restic немного отличается от традиционных систем резервного копирования, и я хочу, чтобы это убеждение подтвердилось, и, возможно, я смогу использовать rsync меньше, а Restic больше.

Например, очень распространенный для меня вариант использования - мы будем использовать rsync для копирования локальной файловой системы в удаленную файловую систему NFS, которая сама по себе является моментальным снимком и резервной копией. Но другие примеры включают использование rsync для получения данных из локальной файловой системы на производственном сервере на локальный файловый сервер на резервном сервере, а затем создание резервной копии на резервном сервере, так что сам процесс резервного копирования (это может занять несколько часов). (особенно если это резервное копирование на основе приложений) не приводит к снижению производительности на производственном сервере. (Иногда мы становимся более привлекательными, чем это ... и мы клонируем том iSCSI, на котором размещены данные, и монтируем его на резервном сервере, и создаем резервную копию ...)

Я хочу сказать, что любому из нас, в том числе и мне, очень легко взглянуть на свой собственный опыт и сделать простые и быстрые выводы о том, как мы делаем что-то и почему другие люди не должны делать это правильно. Но, если не учитывать требования других людей - трудно сказать, делают ли они это неправильно или нет. На этот вопрос есть несколько ответов.

@ d3zd3z

Rsync не использует ctime.

Rsync не использует ctime, потому что не может. Речь идет о синхронизации двух каталогов. Поскольку ctime не может быть установлен, нет смысла сравнивать его с чем-либо.

Это сильно отличается от чего-то вроде restic (или почти любого другого решения для резервного копирования), где хранится ctime. В этом случае он заставляет сравнить ctime с тем, что хранится в резервной копии. Я бы пошел так далеко, чтобы утверждать, что сравнение ctime - это единственный способ правильно создать резервную копию всего, и именно поэтому, насколько я могу судить, каждая система резервного копирования (кроме rsync, которую я бы на самом деле не называл резервной копией) использует ctime, чтобы определить, что нужно резервировать.

Rsync - это совсем другой инструмент, чем Restic.

Если можно, я на мгновение поиграю в адвоката дьявола, чтобы лучше подумать об этих инструментах:

Чем Restic принципиально отличается от Rsync? Rsync синхронизирует два дерева каталогов, удаленных или локальных. Restic эффективно синхронизирует два дерева каталогов, одно из которых смонтировано локально, а другое является виртуальным деревом, хранящимся в репозитории резервных копий Restic. Конечно, есть миллион вариантов, и Rsync - очень гибкий и мощный инструмент. Он даже может создавать резервные копии (настоящие), используя жесткие ссылки в месте назначения. Но по сути, разве они не делают одно и то же: синхронизируют два дерева каталогов?

Если так, то по этой логике, если Rsync не использует ctime, зачем использовать Restic? Это просто оптимизация для хранения ctime и сравнения его вместо других метаданных?

Спасибо вам и @MarkMielke за

Если так, то по этой логике, если Rsync не использует ctime, зачем использовать Restic?

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

Как я уже упоминал ранее, сравнение метаданных миллионов файлов (без сравнения содержимого) может быть довольно дорогостоящим.

Если так, то по этой логике, если Rsync не использует ctime, зачем использовать Restic? Это просто оптимизация для хранения ctime и сравнения его вместо других метаданных?

Rsync не использует ctime, потому что не может, а не потому, что не должен. Другой пример - Unison, который действительно использует ctime. Он также хранит базу данных для каждой стороны, в которой хранятся метаданные файла (в основном ctime), чтобы он мог определять, когда файл изменяется.

Основное отличие состоит в том, что restic делает несколько снимков файловой системы и сохраняет их все. rsync пытается синхронизировать один каталог с другим без сохранения каких-либо других данных. Он делает все возможное, ничего не сохраняя, но поскольку у него нет возможности узнать, какой был ctime раньше, он действительно не может точно узнать, изменилось ли что-то.

Restic не «синхронизирует», он делает снимок. Он отлично работает без ссылки на старую резервную копию и даже должен сохранять тот же результат (из-за дедупликации). Поскольку мы можем сохранить ctime, его можно сравнить с исходным, чтобы сделать эту оптимизацию более надежной, чем простое предположение на основе других параметров.

Что касается сбоев rsync. Чтобы уточнить, я не верю, что rsync когда-либо использует ctime. Он сравнивает только два дерева, и, поскольку ctime не может быть установлен, он не может установить то же значение, что и исходный файл. Он сравнивает только mtime и, возможно, другие атрибуты. У меня он потерпел неудачу, когда пакет debian заменил сжатый файл повторным сжатием того же файла. Для mtime было установлено время исходного файла, и он повторно сжался до того же размера. Но поскольку заголовок gzip имеет отметку времени, содержимое было другим. В данном случае это не имело большого значения, кроме случаев, когда я попросил dpkg проверить содержимое установленных пакетов, и хеш файла был неправильным.

Фууу. :-) Плохая программа сжатия. :-)

Restic не «синхронизирует», он делает снимок. Он отлично работает без ссылки на старую резервную копию и даже должен сохранять тот же результат (из-за дедупликации). Поскольку мы можем сохранить ctime, его можно сравнить с исходным, чтобы сделать эту оптимизацию более надежной, чем простое предположение на основе других параметров.

Это семантика. :-)

Мне нравится, когда прорывные технологии, такие как Git, полностью меняют образ мышления людей (включая то, как они, вероятно, сформировали Restic), но насколько фундаментально это связано с какой-то простой концепцией, такой как передача данных из одного места в другое настолько эффективно, насколько это возможно, не нарушая его.

Коммиты Git - это снимки файловой системы. Вы можете спорить, является ли создание коммита Git синхронизацией или моментальным снимком, но эффект на самом деле тот же. Вы захватываете состояние из одной системы и описываете его в другой системе таким образом, чтобы вы могли воспроизвести исходную систему +/- некоторые артефакты. Забавно для меня ... Git также не хранит ctime. :-)

Забавно для меня ... Git также не хранит ctime. :-)

Кроме того, не правильно. Индекс git хранит ctime (и mtime) каждого файла, и если ctime изменяется, он повторно хеширует файлы. Его поведение практически идентично тому, как это делает Рестик. Формат индекса Git .

Моя ошибка. Прости. :-) Красивый шрифт его исключает. :-)

(Хотя здесь возникает вопрос, для чего он на самом деле используется ... поскольку, если он действительно перефразирует файл для каждой новой рабочей области, Git на самом деле не будет работать ... требуется исследование ...) -

ОБНОВЛЕНИЕ: индекс используется только для быстрого обнаружения изменений в рабочем дереве. У него также есть похожие опции, такие как trustctime, с забавной особенностью:

       core.trustctime
           If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time is regularly modified by something outside Git (file
           system crawlers and some backup systems). See git-update-index(1). True by default.

И в git-update-index:

       The command also looks at core.trustctime configuration variable. It can be useful when the inode change time is regularly modified by something outside Git (file system
       crawlers and backup systems use ctime for marking files processed) (see git-config(1)).

Видимо какие системы бэкапа обновляют ctime? :-) Фу ....

(Хотя здесь возникает вопрос, для чего он на самом деле используется ... поскольку, если он действительно перефразирует файл для каждой новой рабочей области, Git на самом деле не будет работать ... требуется исследование ...) -

Если вы скопируете рабочую область git в другое место (или восстановите из резервной копии), git действительно перепишет каждый файл.

Видимо какие системы бэкапа обновляют ctime?

Например, в gnu tar есть опция --preserve-atime , которая после доступа к файлу устанавливает время, следствием чего является обновление ctime.

Я не знаю ничего, что использует ctime для отметки обработанных файлов, или как это вообще будет работать. Я предполагаю, что они изменяют mtime или atime, что приводит к обновлению ctime.

Если так, то по этой логике, если Rsync не использует ctime, зачем использовать Restic? Это просто оптимизация для хранения ctime и сравнения его вместо других метаданных?

Rsync не использует ctime, потому что не может, а не потому, что не должен. Другой пример - Unison, который действительно использует ctime. Он также хранит базу данных для каждой стороны, в которой хранятся метаданные файла (в основном ctime), чтобы он мог определять, когда файл изменяется.

Unison - особенно интересный пример, поскольку он использует протокол передачи Rsync (но не алгоритм обнаружения изменений Rsync). Из его руководства:

Быстрое обнаружение обновлений
Если ваши реплики большие и хотя бы одна из них находится в системе Windows, вы можете обнаружить, что метод Unison по умолчанию для обнаружения изменений (который включает сканирование полного содержимого каждого файла при каждой синхронизации - единственный полностью безопасный способ сделать это в Windows) работает слишком медленно. Unison обеспечивает быструю проверку предпочтений, которая, если установлено значение true, заставляет использовать время создания файла в качестве «псевдо-индексных номеров» при сканировании реплик на предмет обновлений вместо чтения полного содержимого каждого файла.

Если для fastcheck установлено значение no, Unison будет выполнять медленную проверку - повторное сканирование содержимого каждого файла при каждой синхронизации - на всех репликах. Когда fastcheck установлен по умолчанию (что, естественно, является значением по умолчанию), Unison будет использовать быстрые проверки на репликах Unix и медленные проверки на репликах Windows.

Эта стратегия может привести к тому, что Unison пропустит распространение обновления, если время модификации и длина файла не изменились при обновлении. Однако Unison никогда не перезапишет такое обновление изменением из другой реплики, поскольку он всегда выполняет безопасную проверку обновлений непосредственно перед распространением изменения. Таким образом, разумно использовать этот переключатель большую часть времени и иногда запускать Unison один раз с параметром fastcheck, установленным на no, если вы беспокоитесь, что Unison мог пропустить обновление.

Fastcheck (всегда) автоматически отключается для файлов с расширением .xls или .mpp, чтобы Unison не сбивался с толку из-за привычек определенных программ (в частности, Excel) обновлять файлы без изменения времени их модификации.

Так много некорректных программ. :)

Основное отличие состоит в том, что restic делает несколько снимков файловой системы и сохраняет их все.

Rsync может сделать это с резервными копиями жестких ссылок, каждая из которых является моментальным снимком.

rsync пытается синхронизировать один каталог с другим без сохранения каких-либо других данных. Он делает все возможное, ничего не сохраняя, но поскольку у него нет возможности узнать, какой был ctime раньше, он действительно не может точно узнать, изменилось ли что-то.

Интересно, реализовал ли кто-нибудь своего рода «кеш ctime» для Rsync, чтобы ускорить сравнение больших деревьев.

Restic не «синхронизирует», он делает снимок. Он отлично работает без ссылки на старую резервную копию и даже должен сохранять тот же результат (из-за дедупликации).

Разве создание снимка принципиально не синхронизирует данные от источника к месту назначения в снимке? Логически это синхронизация данных из одного места в другое, независимо от форматов. Представьте, что вы монтируете снимок Restic с помощью FUSE, а затем запускаете Rsync для него (хм, это может быть полезным способом проверить содержимое снимка после его создания).

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

Так что это просто оптимизация, которая зависит от ожидаемого поведения файловой системы, верно?

Я пришел сюда, потому что хотел бы, чтобы он игнорировал ctime. Я нашел переключатель --ignore-inode, но он не помогает в отношении ctime.

Я предлагаю ко всему этому обсуждению добавить такой переключатель, как:
--ignore-ctime

@ geri777 Поскольку это отдельный запрос функции, откройте новую проблему (выберите «Запрос функции» в качестве типа, когда его спросят об этом) и заполните там шаблон. Также объясните вариант использования запроса.