Restic: Пропустить создание снимка, если не было изменений

Может быть, было бы неплохо создать своего рода псевдоним.

Нам нужно будет определить, что означает «без изменений»: «Файлы не были добавлены / удалены, и нет файлов с другим содержимым» и / или «Нет метаданных и содержимое не изменилось».

Как обсуждалось в IRC: отказ от создания нового снимка может нарушить политику forget ...

Мне любопытно: зачем вам эта функция? Какой у вас вариант использования?

Мне любопытно: зачем вам эта функция? Какой у вас вариант использования?

Я просто почувствовал, что нет необходимости загромождать репозиторий снимками, которые мне не нужны.
Мой вариант использования - это набор файлов, резервные копии которых я хочу делать два раза в день, но они меняются нечасто (раз в месяц, может быть, даже реже). Это оставило бы меня с ~ 59 «пустыми» снимками в месяц в моем репо, что, вероятно, замедлило бы работу (поскольку это удаленный репозиторий с большим временем приема-передачи). Я мог бы регулярно запускать forget & prune но это будет стоить обходов, а также вызовов API и т. Д.

В общем, это "приятно иметь", так как есть много способов обойти это (или лучше: правильно использовать restic: smiley :). Я просто хотел поднять это, как я думал об этом, и, возможно, другие.

Спасибо за объяснение. При построении restic и структуры репозитория я имел в виду, что «моментальный снимок» фиксирует состояние данных в определенный момент времени. Если данные вообще не изменились по сравнению с любым предыдущим снимком, дополнительный снимок стоит очень дешево и использует всего несколько сотен байт и один дополнительный файл в репозитории. Вы правы в том, что большее количество снимков может немного замедлить работу, особенно для удаленных бэкэндов с высокой задержкой, но я убежден, что этот эффект незначителен. Если это не так, мы определенно можем оптимизировать его (сравните # 523), но тогда я хотел бы сначала измерить / протестировать, чтобы получить точные данные :)

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

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

Читая журнал чата IRC, кажется, что добавить это не составит большого труда. Можно ли добавить это в качестве флага для резервного копирования, чтобы у пользователей был хотя бы выбор?

Хотя сам я бы никогда не использовал такую ​​возможность, я хотел бы ответить на вопрос, что должно означать «без изменений».

@ fd0 заявил

«Файлы не были добавлены / удалены, и нет файлов с другим содержимым» и / или «Нет метаданных и содержимое не изменилось».

ИМХО, единственный допустимый выбор здесь - это вариант «И»:

• Никакие узлы (каталоги, файлы, символические ссылки, устройства, специальные устройства и т. Д.) Не были добавлены или удалены, И
• Нет файлов с разным содержанием, И
• Метаданные (разрешения, владелец, группа, ctime, mtime и т. Д.) Не изменились.

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

Я считаю, что есть некоторые проблемы, которые требуют сбора статистики во время резервного копирования (например, # 693, # 874). Я предполагаю, что необходимый им код сбора статистики здесь тоже пригодится.

@ ignus2 спасибо за описание ваших ожиданий и вашей реакции, это очень ценно для нас как для проекта!

Моментальные снимки Restic можно сравнить больше с «снимками виртуальных машин» или «снимками файловой системы lvm / zfs», чем, например, с файлом tar того, что изменилось. Если ничего не изменилось, создается снимок для записи «это была текущая статистика» в определенный момент времени. Может, стоит добавить это в руководство.

Можно ли было бы добавить флаг для пропуска создания снимка, если ничего не изменится?

Можно было бы добавить это, но я не думаю, что мы добавим это: это просто не то, как работает restic, и вызовет проблемы при использовании команды forget .

Это не изменит способ работы restic по умолчанию, поскольку это будет необязательный флаг. Какие проблемы могут возникнуть при использовании команды "забудьте", кстати?

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

Я не помню: вы объяснили, почему наличие «пустых» снимков является такой проблемой для вашего варианта использования?

-
Майкл Л. Бэрроу
Майкл в кургане меня расставить
+ 1.541-600-2027

11 октября 2017 г. в 06:04 Балаж Ороси [email protected] написал:

Это не изменит способ работы restic, поскольку это будет необязательный флаг. Какие проблемы могут возникнуть при использовании команды "забудьте", кстати?

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Идея команды forget (как объясняется, например, в этой записи блога ) заключается в том, что вы указываете политику для моментальных снимков, которые хотите сохранить. Если у вас есть только снимки, когда данные были изменены, указывать, например, --keep-daily больше не имеет смысла.

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

Кстати, если вам действительно нравится это делать, вы можете использовать restic snapshots --json , затем взять идентификаторы снимков, использовать restic cat snapshot <id> для каждого и отбросить те, где идентификаторы деревьев не изменились. Это равносильно удалению «пустых» снимков.

Да, я знаю, что они не пустые. Я просто использовал этот термин, чтобы более точно описать их для этого конкретного сценария; "пустой" означает, что OP практически не имеет значения, исходя из критериев отсутствия изменения файлов.

-
Майкл Л. Бэрроу
Майкл в кургане меня расставить
+ 1.541-600-2027

11 октября 2017 г. в 07:30 Александр Нойман [email protected] написал:

Идея команды "забыть" (как объяснено, например, в этой записи блога) заключается в том, что вы указываете политику для моментальных снимков, которые хотите сохранить. Если у вас есть только снимки, когда данные были изменены, указывать, например, --keep-daily, больше не имеет смысла.

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

Кстати, если вам действительно нравится это делать, вы можете использовать restic snapshots --json, затем взять идентификаторы снимков, использовать restic cat snapshotдля каждого и отбросьте те, у которых идентификаторы деревьев не изменились. Это равносильно удалению «пустых» снимков.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Я собираюсь снова открыть этот номер.

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

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

Я хотел бы еще раз подчеркнуть, что это будет дополнительная функция для тех, кто хотел бы использовать restic немного по-другому, кто, возможно, никогда не будет использовать функции keep-daily и т. Д., Забыть вообще.

Кстати, спасибо, что упомянули обходной путь.

Мне любопытно: есть ли такая опция в других программах для резервного копирования?

Мне любопытно: есть ли такая опция в других программах для резервного копирования?

Я не знаю, но если так, то рестик тоже должен, если нет, рестик мог бы быть уникальным в этом отношении;)

Кстати, я, кажется, понимаю сопротивление этой функции, поскольку restic делает акцент на «когда» или «время» резервного копирования (также указывается в способе работы функции «забыть», ориентированной на время), следовательно, на моментальный снимок во времени. В то время как вариант использования, который я имею в виду (и, возможно, OP тоже), больше внимания уделяется «изменениям» с дополнительной дополнительной информацией «когда».

РЕДАКТИРОВАТЬ: что-то вроде git или думать о restic, как то, как работает git (с точки зрения конечного пользователя), является совершенно плохой идеей?

ИМХО, такой "сообразительности" нет места в ПО для резервного копирования. Если я попрошу программу резервного копирования сделать резервную копию, я бы хотел, чтобы она не играла в игры за моей спиной, не имела собственного мнения, ничего не изменилось и т.д. разве нет ?!

Давайте будем простыми: если нет ничего нового для резервного копирования, ну ... тогда не создавайте резервные копии! Выберите стороннее программное обеспечение для резервного копирования, а затем отправлять резервную копию или нет. Слишком умное ПО для резервного копирования было бы ненадежным ПО для резервного копирования. Хотелось бы, чтобы он был надежным, не слишком умным, если это вообще возможно.

Я никогда такого не видел, поэтому использовал слово «необычный», чтобы описать это
особенность в моем предыдущем сообщении.

Другая причина, почему это необычно, заключается в том, что это как бы противоречит концепции.
решения по защите данных. Снимок представляет состояние
мир в то время (вернитесь к объяснению того факта, что
снимки на самом деле не пустые).

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

Майкл в кургане меня расставить
+1.541.600.2027

"Не предвидеть неприятностей, или
беспокоиться о том, что может никогда не случиться.
Держитесь на солнце ». - Б. Франклин.

В среду, 11 октября 2017 г., в 8:31, Балаж Ороси [email protected]
написал:

Мне любопытно: есть ли такая опция в других программах для резервного копирования?
Не знаю, но если да, то рестик тоже должен, если нет, то рестик можно
уникальный в этом плане;)

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restic/restic/issues/662#issuecomment-335850739 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ABzVspDVasI91Mp4B2hFCMlsCWGr_B-Vks5srN9IgaJpZM4KrXNh
.

@zcalusic Эта «хитрость» будет скрыта за _ необязательным _ переключателем командной строки, поэтому он затронет только тех пользователей, которые специально об этом просят.

@ ignus2 : Я понимаю, но любой код, добавленный в базу кода, необходимо тестировать и поддерживать с течением времени. Кроме того, похоже, что ваш запрос очень уникален.

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

Второй комментарий @ ignus2 о необязательном переключателе.
Очевидно, что есть разные варианты использования restic.

Некоторые хотят делать «традиционные» резервные копии, скажем, ежедневно, скажем, для большого количества файлов, и иметь возможность восстановить состояние дня X, если что-то плохое произошло в X + 1. Они знают время, когда данные были уничтожены.
Эти пользователи сосредоточены на восстановлении состояния на заданную дату . Они никогда не хотят пропустить моментальный снимок.

Другие (например, я) хотят использовать restic для моментального снимка состояния папки довольно часто, может быть, каждые 30 минут. Тогда состояние на заданную дату не имеет значения, возможно, они не знают, когда данные были повреждены (например, синхронизация файлов). Вместо этого они хотят быстро увидеть, были ли / когда были изменения (например, чтобы иметь возможность отследить точку, где произошло повреждение данных, с минимальным количеством различий).
Эти пользователи сосредотачиваются на моментах времени, когда произошли изменения. Снимки без изменений для них просто раздражают (например, при монтировании резервной копии, чтобы делать различия между каждыми двумя соседними снимками).

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

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

Что ж - у вас есть источник. Выбей себя!

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

Пожалуйста, пока не работайте над этой функцией, я бы сначала переделал код архиватора.

Я хотел бы попробовать еще раз и еще раз объяснить свои сомнения в отношении команды forget , я думаю, что это было недостаточно ясно.

Предположим, у нас есть пользователь, который автоматически запускает restic backup каждые 30 минут (например, через cron). На следующий день они запускают restic forget --keep-hourly 24 .

Прямо сейчас репозиторий будет содержать 24 снимка, по одному на каждый час предыдущего дня.

Если эта функция включена (сохраняются только снимки, в которых изменяются данные), результаты могут сильно отличаться: в репозитории по-прежнему будет храниться до 24 снимков, не более одного в час, но может быть снимок с прошлой недели, за которым следует на один по сравнению с двумя днями ранее. Вы знаете, что forget работает таким образом?

Меня беспокоит то, что forget становится довольно непредсказуемым.

Итак, пока оставляем этот вопрос открытым.

Люди, читающие этот выпуск : если у вас есть вариант использования, который еще не описан (например, использование restic как своего рода системы «контроля версий»), добавьте комментарий.

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

Спасибо!

Хорошо, хотя я уже реализовал базовую версию в качестве первой попытки, и она отлично работает (практически 7 строк кода).

Что касается ваших комментариев о команде forget : здесь это не актуально. Я думаю, что из объяснения @maxhq не было ясно: этот режим работы или флаг (т.е. пропуск снимков без изменений) не должен использоваться и не имеет смысла в случае использования, который включает forget команда. Точно так же команда forget не имеет смысла в сценарии использования, когда задействован пропуск моментальных снимков.

Чтобы быть более ясным: пользователи, которые хотят и должны использовать команду forget , не будут и не должны использовать restic backup с флагом, который пропускает моментальные снимки при отсутствии изменений, и наоборот.

Код подтверждения концепции находится в фиксации ignus2 / restic @ 7ebee9de1838e3d3954ecd36d43db499dd508a17, если кому-то интересно.

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

@ fd0 почему бы и нет?

Я хотел бы немного изучить значение forget .

Если у вас есть только снимки, когда данные были изменены, указывать, например, --keep-daily, больше не имеет смысла.

Вполне вероятно, что я что-то неправильно понимаю, я новичок в restic , но для меня это звучит как противоположное. Я использую это описание в упомянутом вами сообщении в блоге:

Когда --keep-daily установлен, например, на значение 7, тогда restic будет применять аналогичный подход к --keep-hourly : просмотрите список, найдите последние семь дней, в которых хотя бы был сделан один снимок. Для каждого дня сохраняйте последний снимок, сделанный в этот день, помечайте остальные для удаления и удаляйте все снимки из списка.

Давайте рассмотрим последние, скажем, 14 дней, и какой снимок будет или не будет представлен в зависимости от того, создаем ли мы дублирующиеся снимки или нет, и какие снимки будут удалены / останутся не удаленными с помощью --keep-daily .

В целях аргументации предположим, что моментальные снимки на нашем сервере. Сегодня 23:30 14 числа. Предположим, что данные менялись нечасто: они менялись несколько раз 1, 2, 3, 4, 5, 6 и 13 числа месяца. Если мы запустим forget с --keep-daily , например, на значение 7 мы получим 7 снимков, из которых 5 будут идентичными, что, на мой взгляд, не очень полезно. Если, с другой стороны, мы не будем записывать один и тот же снимок снова и снова, все 7 снимков будут разными, что, по ИМО, гораздо более полезно. На самом деле я не знаю, зачем вам хранить 6 одинаковых снимков, насколько я понимаю, это не добавляет ценности.

Я не совсем уверен, что в этом сценарии «непредсказуемо», вы все равно получите свои последние 7 снимков, просто все они будут разными, а не повторяющимися, что, как я уже упоминал, кажется более полезным.

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

Вопрос: какой вообще смысл иметь одинаковые снимки? Чем это полезно?

На самом деле у меня есть альтернативное предложение для исходного сообщения, которое меня удовлетворило бы и могло бы быть более привлекательным для разработчиков, выражающих свои опасения: вместо добавления опции не создавать снимок, добавьте политику forget чтобы найти и удалите все идентичные снимки, кроме самого последнего, в каждом наборе идентичных снимков (если это можно сделать эффективным способом). Я не против запланировать дополнительную команду «забыть» после резервного копирования, чтобы удалить последний снимок, если он был дублирован. Это могло быть лучшим из обоих миров.

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