Автоматическое инкрементное резервное копирование на внешний накопитель

Задний план

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

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

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

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

Предложение

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

  1. Правило udev автоматически монтирует диск
  2. Резервное копирование начинается с:

    1. То же правило udev также запускает скрипт rsnapshot
    2. Событие inotify create определяет новую точку монтирования и запускает rsnapshot
  3. После выхода rsnapshot umount rsnapshot на диске

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

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

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

Вопросов

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

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

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

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

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