Restic: Заставить restic работать без разрешения на удаление файлов на GCS

Эй, спасибо, что подняли этот вопрос. Параметр --no-lock предназначен только для поддерживаемых операций, таких как check . Любая операция, которая может добавлять данные (например, backup ), не поддерживает ее, это не то, как было разработано репо.

Возможно ли разрешить удаление учетной записи службы в подкаталоге locks/ ?

Или сделать резервную копию в локальный каталог, а затем использовать, например, rclone для синхронизации новых файлов с облаком?

Возможно ли разрешить удаление служебной учетной записи в замках/подкаталоге?

Это невозможно в GCS.

@ fd0 restic backup с --no-lock здесь работает, и я автоматически удаляю все под /locks через несколько часов.

% myrestic check
password is correct
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

нет, это невозможно из-за ограничений по размеру.

@gebi «это работает» означает, что restic не возвращает ошибку, когда вы указываете --no-lock , но для операции backup он все равно создает файл блокировки. Переключатель --no-lock проверяется для каждой операции отдельно, и только некоторые (например, check ) его соблюдают.

Я понимаю ваш вариант использования, но я должен сказать, что мне очень не хочется добавлять поддержку --no-lock в backup из-за высокого потенциала, который люди используют, не понимая, для чего это нужно. Например, предположим, что резервное копирование занимает намного больше времени, чем предполагалось, и пока резервное копирование (без блокировки) все еще выполняется, операция prune запускается на другом компьютере. Он не увидит никакой блокировки, а поскольку другой процесс еще не завершен, он не увидит созданный им снимок. Таким образом, процесс удаления не будет знать, на какие данные ссылается новый снимок, и даже удалит недавно загруженные файлы, поскольку на них не ссылается ни один существующий снимок. Затем выполняется процесс резервного копирования, загружается новый индекс (со ссылкой на удаленные файлы) и новый снимок, который больше нельзя восстановить.

Как убедиться, что при запуске prune restic backup

@fd0 Учетная запись службы, используемая restic, просто не может удалять файлы в корзине GCS. Таким образом, конфликт между этими двумя командами невозможен.

ИМХО, было бы очень важным свойством и стоящей целью поддерживать GCS в качестве защищенного от несанкционированного доступа хранилища в restic, потому что злоумышленники чаще всего удаляют все, что могут найти, включая резервные копии, с учетной записью службы с полными разрешениями на удаление/перезапись. резервное копирование фактически бесполезно.

@fd0 , но, как вы сказали, должно быть напечатано предупреждение о возможности повреждения данных, если какая-то привилегированная учетная запись выполняет prune параллельно (возможно, можно подавить с помощью некоторых я знаю, что я делаю выключатель).

ах... и restic prune никогда не вызывается в этих пулах данных, они сегментированы по годам и удаляются только целые годы (потому что удаление отдельных снимков из репозитория не нужно и слишком медленно).

@ fd0 Есть идеи по моему предложению?
Если я правильно понимаю код, он просто не будет создавать файлы блокировки и, таким образом, автоматически будет чистый выход из restic (в настоящее время его нужно убить с помощью -9).

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

Что касается параллельных черносливов, почему бы не использовать двухфазную «фиксацию» для черносливов?
restic prune записывает в файл только объекты, которые он удалит, при следующем запуске он будет работать в обычном режиме, что означает сначала создать список объектов для удаления из всего репозитория, а затем удалить только файлы, найденные в списке. написано на бегу раньше. Все объекты, которых нет в списке, выписываются в новый список. Это устранило бы необходимость в какой-либо блокировке с гарантией безопасности, чтобы не удалять объекты из запущенных резервных копий, которые были короче интервала удаления (что, если удаление выполняется только каждый месяц, является довольно хорошим запасом безопасности).
Эта идея будет иметь дополнительное преимущество, заключающееся в том, что не потребуется также новый формат репозитория.

См. № 1141 для обсуждения обрезки без блокировки.

@ifedorenko да, я читал обсуждение, но, как уже упоминалось там, подход duplicacy нуждается в обновлении формата репозитория, этот простой, хотя и не такой причудливый подход не имеет и не имеет обширных требований относительно атомарности. операций в бэкэнд-магазине.

Я просто предложил обсудить prune без блокировки в #1141, чтобы у нас были все идеи в одном месте.

Я решил не добавлять поддержку --no-lock для резервного копирования, по крайней мере, пока. Если вам нужно такое поведение (и мне кажется, что вы знаете, что делаете), один из способов — вручную исправить его в restic и создать его самостоятельно. Вот патч: https://gist.github.com/fcaf7a0cbc35b4e0bebc901fbacd3860

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

Я разветвил restic и сделал первый выпуск restic-worm, который мы должны использовать, и буду обновлять его до вашего upstream restic, поскольку это имеет смысл для нашего варианта использования.
В настоящее время он выполняет резервное копирование около 10 ПБ данных и до сих пор работает нормально, я бы очень хотел, чтобы мы нашли возможность работать вместе и добавить эту функциональность в восходящий поток, даже если это означало, что нам придется тестировать ее и поддерживать в форме, форк не помогает обеим сторонам.

https://github.com/mgit-at/restic/tree/v0.8.3-червь
https://github.com/mgit-at/restic/tree/backup-nolock

@gebi Я могу понять ваш вариант использования и то, что вы пытаетесь сделать. На мой взгляд, простое добавление небольшого патча, разрешающего --no-lock во время резервного копирования, может быть использовано слишком большим количеством пользователей неправильным образом, что может привести к потере данных. Вот почему я не люблю просто добавлять его.

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

Я согласен с тем, что вилка неудачна и не поможет нам обоим, даже если это всего лишь дополнительные --no-lock для поддержки вашего варианта использования. Я мог бы жить с патчем, который включает это только со специальным флагом сборки worn , который полностью отключает команду prune и запускает backup и check без файлов блокировки. . Может быть, это сработает для вас?

Мне очень интересны ваши результаты работы с 10PB в репозитории, это круто!

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

Так почему бы не позволить restic snapshot --no-lock создать файл блокировки, если его еще нет, а просто не удалить его?
Это запретило бы restic выполнять какие-либо операции обрезки данных параллельно, но не ограничило бы будущие моментальные снимки (насколько я вижу, они просто работают, независимо от того, сколько файлов блокировки присутствует).

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

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

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

Я полагаю, вы имеете в виду restic backup --no-lock ? Это будет работать для backup , но со временем вы получите много файлов блокировки...

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

@ fd0 да, я имел в виду restic backup --no-lock , да, результатом будет много файлов блокировки, но их можно либо удалить с машины, обрезающей данные, либо сначала проверить, существует ли хотя бы один файл блокировки, и создать новый, только если файл блокировки не существует.

А для таких операций, как snapshots , это будет либо такое же поведение, как сейчас, либо игнорирование ошибки?

Хм. Может быть, мы действительно можем это сделать: не выходить с ошибкой, если файл блокировки не может быть удален. Это сработает в большинстве случаев, особенно в тех, которые вас интересуют.

Да, это было бы здорово!

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

О, это нехорошо, спасибо, что снова указали на это.

Я думаю, вы должны иметь возможность добавлять полные права на запись и удаление только для папки блокировки с помощью ACL:
https://cloud.google.com/storage/docs/access-control/lists

Хотя сам не проверял и могу ошибаться.

@lukastribus было бы здорово, если бы это сработало, но это не так.

Нет блокировки «папки» / для размещения на ней ACL, корзины облачного хранилища Google так не работают, извините.
Можно было бы поместить ACL для каждого отдельного объекта в пространстве имен lock/ , но это лишило бы цели.

@ fd0 есть новости о функции «Хм. Может быть, мы действительно можем это сделать: не выходить с ошибкой, если файл блокировки не может быть удален. Это сработает в большинстве случаев, особенно в тех, которые вас интересуют».

Было бы действительно здорово, если бы вы могли добавить это в restic, это сделало бы нашу жизнь намного проще, и это было бы ИМХО стоящим дополнением.

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

@ fd0 есть новости о функции «Хм. Может быть, мы действительно можем это сделать: не выходить с ошибкой, если файл блокировки не может быть удален. Это сработает в большинстве случаев, особенно в тех, которые вас интересуют».

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

Одна небольшая проблема, которая здесь не упоминается (насколько я понимаю), заключается в том, что при выполнении длительных операций, таких как backup , restic заменяет свой собственный файл блокировки каждые несколько минут новым с новым название. Таким образом, нет «одного» файла блокировки, а их множество.

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

Хорошее замечание, хм.

Основой этого обсуждения является создание доступного для резервного копирования флага --no-lock , который уже существует в виде кода (от вас). Это также то, что мы в настоящее время используем для резервного копирования всего.

@ fd0 какой бы вы предпочли способ? Я отправил патч, который мы используем, поверх restic (который, к счастью, был предоставлен вами, я только что перебазировал его для master). № 1917

Может быть, другим способом может быть вариант хранения файлов блокировки отдельно (например, в корзине, к которой у вас ДЕЙСТВИТЕЛЬНО есть доступ для записи)?

Интересно, что все остальные делают, чтобы разрешить эту ситуацию с безопасностью? Если машина резервного копирования скомпрометирована, как убедиться, что злоумышленник не удалит все резервные копии?

Я тоже сталкиваюсь с этой проблемой. У меня нет необходимости (и из-за требований к данным я не могу) обрезать резервные копии. Запуск резервного копирования --no-lock был бы идеальным решением для меня. Есть ли жизнеспособный обходной путь?

@parkerp1 Мы эффективно используем метод, предложенный здесь , который заключается в том, чтобы Restic общался с двумя копиями rclone, перед которыми стоит tinyproxy, и имея одно ведро для чтения/записи для файлов блокировки и одно ведро только для записи для данных. Статья посвящена васаби, но серверная часть не имеет значения, и мы используем его с GCS. Хотя это и не очень чисто, Dockerizing этого решения помогает скрыть сложность.

@parkerp1 мы все еще используем небольшой патч поверх restic https://github.com/mgit-at/restic/tree/backup-nolock для резервного копирования нескольких сотен ТБ данных. Работает как шарм.
К сожалению, он был отклонен выше по течению ...

Спасибо @gebi и @sdudley. Оба выглядят как хорошие варианты

Я согласен с @fd0 , что добавление флага --no-lock было бы опасно. Если кто-то получал ошибку блокировки, он мог попытаться добавить этот флаг, чтобы обойти его и в конечном итоге повредить свои данные.

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

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

Я тоже сталкиваюсь с этой проблемой. У меня нет необходимости (и из-за требований к данным я не могу) обрезать резервные копии. Запуск резервного копирования --no-lock был бы идеальным решением для меня. Есть ли жизнеспособный обходной путь?

Два варианта навскидку:

• Используйте rest-server с флагом --append-only — это позволит вашим пользователям создавать резервные копии только в своих репозиториях, они не смогут удалять данные.

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

Другим подходом может быть использование управления версиями объектов . Если это включено, удаление может быть разрешено для служебной учетной записи, используемой restic, поскольку они фактически добавляют только маркеры удаления в историю версий. Только в разрешении на действие DeleteObjectVersion должно быть отказано, чтобы злоумышленник не нанес непоправимый ущерб.
Честно говоря, я не уверен насчет GCS, но в настоящее время я реализую это на S3/Wasabi, и это выглядит многообещающе.

@ fd0 Будет ли переменная среды типа RESTIC_DANGEROUSLY_DO_NOT_LOCK_BACKUP вариантом? :)

@ fd0 Может ли переменная среды типа RESTIC_DANGEROUSLY_DO_NOT_LOCK_BACKUP быть вариантом? :)

Нет, я так не думаю. Я изложил в https://github.com/restic/restic/issues/1544#issuecomment -386549926:

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