Restic: Незашифрованные резервные копии

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

Длинная версия:

• Шифрование больше не является дорогим, по крайней мере, если у вас есть AES-NI (аппаратное ускоренное шифрование), которое в наши дни довольно распространено (по крайней мере, в ноутбуках и серверах).
• restic заботится не только о шифровании, но и о подлинности и подписи данных. Нам нужно найти способ реализовать это без шифрования, поэтому нам все равно нужно сохранить ключ / пароль.
• Когда у нас есть кодовый путь, который позволяет создавать незашифрованные резервные копии, есть вероятность, что злоумышленники найдут способ обманом заставить клиента сохранить данные без шифрования в (изначально) зашифрованном репозитории. Такое случалось с другими программами резервного копирования и раньше, поэтому нам нужно быть очень осторожными, что требует времени и ресурсов, которых у нас нет в данный момент.

Я могу добавить дополнительные баллы, когда найду их.

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

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

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

@wrouesnel, вы уже можете это сделать, различая по имени хоста! (Мне было интересно то же самое на днях) :)

@alexeymuranov, как определить, является ли введенный пользователем пароль паролем шифрования для зашифрованного каталога или паролем MAC для проверки подлинности незашифрованного каталога? еще --switches ? Очень быстро становится очень грязно.

Я бы хотел иметь эту возможность для создания локальных резервных копий. Например, каждый день я запускаю резервную копию моего каталога ~ / Music на моем сервере, но мне не нужно, чтобы это было зашифровано. Резервное копирование предназначено не для защиты от аппаратного сбоя или потери (у меня есть другие резервные копии для этого), а просто для защиты от несчастных случаев и битрота. И сервер довольно маломощный, поэтому накладные расходы на шифрование являются проблемой.

@alphapapa для этого есть rsync .
РЕДАКТИРОВАТЬ: И разрешения / атрибуты файлов. Кстати, в чем разница между "аппаратным сбоем" и "битротом"?

@cfcs , rsync не выполняет дедупликацию.

для этого есть rsync.

@cfcs Как мы все знаем, зеркало не является резервной копией. ;) Используя Obnam, я храню серию резервных копий, похожих на restic: keep = 7d,8w,12m,3y С тех пор, как я чуть не потерял свой ключ GPG (потому что он был таинственным образом усечен до 0 байтов без моего ведома, а усеченный файл был скопирован неоднократно), и мне пришлось выкопать его из резервной копии многолетней давности на CD-R, я осознаю важность сохранения старых данных резервной копии.

Кстати, в чем разница между "аппаратным сбоем" и "битротом"?

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

И, как отмечает Алексей, rsync не выполняет дедупликацию и не обеспечивает удаление старых данных резервных копий, проверку целостности данных и т. Д. Rsync - прекрасный инструмент, и я использую его регулярно, но не для создания резервных копий .

Шифрование больше не является дорогим, по крайней мере, если у вас есть AES-NI (аппаратное ускоренное шифрование), которое в наши дни довольно распространено (по крайней мере, в ноутбуках и серверах).

Если ваше программное обеспечение не написано на go. Crypro от Go - это программное обеспечение только для чего-либо, кроме Intel, поэтому с устройством arm вы застряли с «расчетным временем резервного копирования - 14 дней» для того же набора файлов, который завершается менее чем за 30 минут с официальным решением для резервного копирования на основе openssl на моем NAS .

Я бы тоже хотел увидеть эту функцию. Я использую SSH для передачи и храню свои резервные копии на зашифрованных томах LUKS / cryptsetup, поэтому шифрование просто увеличивает риск потери ключа шифрования. Кроме того, шифрование увеличивает вероятность ошибок и увеличивает ненужную нагрузку на ЦП.

Тем не менее, шифрование очень полезно, когда я выполняю резервное копирование на ненадежную цель.

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

Я также использую зашифрованную цель резервного копирования luks / dm-crypt. Это внешний USB-диск, который я подключаю к / Backup /
Вы можете просто создать файл паролей в этом месте (/ Backup / restic_password) и передать его в состояние restic с помощью --password-file. Репозиторий находится в / Backup / restic_repo /
Важно сделать файл паролей неизменяемым, иначе вы облажаетесь, если он случайно потеряется: chattr + i / Backup / restic_password
Также на всякий случай я использую "restic" в качестве пароля.

Функция шифрования Restic очень полезна при резервном копировании на ненадежные объекты, такие как облачные провайдеры. Но если вы просто используете внешние диски, которые храните дома, или NAS в подвале, принудительное шифрование - это своего рода безумие. Обычный пользователь все равно забудет пароль.

Разрешение незашифрованного резервного копирования позволит ZFS, BtrFS или NTFS или любой другой файловой системе сжимать резервные копии.

(При желании шифрование может быть выполнено через dmcrypt на более низком уровне)

Разрешение незашифрованного резервного копирования позволит ZFS, BtrFS или NTFS или любой другой файловой системе сжимать резервные копии.

То же самое, отсутствие сжатия и обязательное шифрование занимает слишком много места на моем сервере резервного копирования. Мой вариант использования (некоторые изображения, множество небольших файлов xml / txt / csv) сильно выиграет либо от отсутствия шифрования (чтобы ZFS мог делать свое дело), ​​либо от сжатия (коэффициент сжатия ~ 2,3 с zstd, 5).

Если вы используете ZFS, почему бы просто не использовать снимки zfs send ?

Моментальных снимков ZFS во многих случаях недостаточно для резервного копирования. Если у вас есть необнаруженное повреждение в файле или если вы хотите, чтобы у вас были наборы сохранений за годы, снимки файловой системы ZFS не очень помогают. Например, вы используете FreeNAS и хотите поддерживать еженедельное резервное копирование в течение года. Планирование и управление моментальными снимками, встроенные в FreeNAS, _ действительно_ недостаточно, чтобы выполнить это правильно. Это не «предприимчивость».

Если у вас есть более сложная система планирования, она, вероятно, будет работать намного лучше. Также существует проблема отправки zfs, требующей наличия моментального снимка, прежде чем вы сможете его отправить; вам также необходимо управлять расписанием моментальных снимков и убедиться, что ваш снимок и расписание отправки синхронизированы (вручную), чтобы вы достигли своего RTO / RPO.

И да ... Я говорю о корпоративных функциях FreeNAS. Но это проблема ...

Шифрование теперь не дорогое удовольствие, по крайней мере, если у вас есть AES-NI.

Требование AES-NI исключает множество старых серверов (которые в некоторых случаях _ особенно важно_ выполнять резервное копирование!).

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

+1 за без шифрования

это было бы полезно

+1 за без шифрования

это было бы полезно

Чтобы избежать переполнения почтовых ящиков наблюдателей, используйте в исходном выпуске отметку «Нравится» вместо «+1». Спасибо!

Каков статус этой функции?

Мне нужно сделать резервную копию файлов (общих документов, таких как переводы руководств пользователя) с внутреннего сервера Samba, к которому все пользователи в компании в любом случае имеют доступ, они не являются конфиденциальными в пределах компании. Шифрование резервных копий в этом случае бессмысленно, я все равно использую jailkit для дополнительной безопасности резервных копий, и я использую файловую систему btrfs с включенным сжатием. В любом случае я делаю резервные копии таких вещей, как дампы дисков ВМ, другими способами. В моем случае шифрование не является проблемой, единственная приоритетная задача - предотвращение потери данных. Использование пароля типа «restic» - своего рода глупый обходной путь.

Пожалуйста, примените это.

@mrkafk Какая у вас настоящая проблема с restic, имеющим шифрование? Даже если вам это не нужно, вам понадобятся очень конкретные причины, чтобы это было проблемой, так как ваши процессоры, скорее всего, поддерживают аппаратное шифрование.

Я описал свою настоящую проблему: учитывая конкретный контекст, он мне не нужен, хотя, как я понимаю, по крайней мере, он устраняет выигрыш от сжатия в файловой системе btrfs. У меня есть тонны файлов для резервного копирования, поэтому я использую btrfs с включенным сжатием в первую очередь, потому что с RAID-1 для избыточности hw мне нужно много дискового пространства (если бы не это, я бы предпочел использовать ext4). Кроме того, шифрование с использованием поддельного пароля и излишнее шифрование кажется ... глупым.

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

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

Мебус

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

Это обсуждалось так, будто мир уже завтра закончится :) https://github.com/restic/restic/issues/1786