Фон

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

Система на базе Arch Linux является автономной, и поэтому решение должно быть полностью автоматизированным, не требующим вмешательства пользователя.

Идеальный сценарий был бы следующим:

1. Пользователь подключает жесткий диск USB
2. Полное инкрементное резервное копирование сделано
3. Жесткий диск размонтирован
4. Пользователь уведомляется о том, что жесткий диск может быть отключен

Предложение

Мое предлагаемое решение состоит из:

1. udevПравило автоматически монтирует диск

2. Резервное копирование начинается с:

   1. Это же udevправило также запускает rsnapshotскрипт
   2. Inotify создать событие определяет новый пункт и спусковые креплениеrsnapshot

3. После rsnapshotвыхода umountзапускается на диске

4. Возможные способы уведомления жесткого диска могут быть удалены:

   1. CD-дисковод открывается
   2. Звук воспроизводится через динамик ПК

Если в какой-то момент произошла ошибка, отправьте электронное письмо пользователю и отключите диск.

Вопросов

1. Мое предложение кажется возможным, но есть ли очевидные недостатки? Как я могу сделать это надежным?
2. В целях безопасности, как я могу убедиться, что подключенный жесткий диск принадлежит пользователю? sshключи? Метка диска?
3. Существуют ли (Linux) решения, которые включают это?

Ваше решение кажется относительно подходящим:

• Убедитесь, что rsnapshotсценарий не предполагает знать блочное устройство. В идеале обращайтесь к файловой системе по ее UUID или метке, чтобы избежать резни.
• Добавьте таймауты. Таким образом, если что-то пойдет не так, о чем мы не знаем, или что-то заставит скрипт никогда не завершиться, его можно рассматривать как ошибку, а не продолжать бесконечно.
• В конце вы заявляете, что «[i] f произошла ошибка в любой момент, отправьте электронное письмо пользователю и отключите диск» - что произойдет, если он не сможет размонтировать диск или произойдет сбой при размонтировании? Что произойдет, если письмо не получится? Убедитесь, что в вашей системе встроены отказоустойчивые файлы.
• Для базовой безопасности UUID должен быть в порядке (если злоумышленник может не знать о вашем UUID), однако, если безопасность более важна, рассмотрите возможность записи некоторых данных в область кода MBR (байты 0-440), и наличие сценария для проверки перед началом резервного копирования. Вы должны быть предупреждены, что это более надежно благодаря мраку, чем чему-либо еще, однако в этой ситуации я не вижу доступных методов, которые лучше. Однако если вы хотите пройти полный путь, вы можете определить, авторизован ли диск, проанализировав зашифрованный сертификат, хранящийся на диске. когдаudevобнаруживает диск, скрипт расшифровывает сертификат, используя его ключ. Сертификат содержит параметры, относящиеся к диску, такие как серийный номер диска, номер модели, емкость и т. Д., Затем сравнивает параметры, извлеченные из зашифрованного сертификата, с параметрами, которые видны при анализе диска. Если параметры совпадают, диск считается подлинным, в противном случае диск отклоняется, и сценарий завершается.

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

Чтобы записать случайные данные в область кода MBR, которую затем можно проверить, выполните что-то вроде dd if=/dev/urandom of=/dev/sdX bs=440 count=1.