Я отвечаю за небольшой набор ноутбуков и хотел получить какое-то автоматическое удаленное (через WAN) резервное копирование; резервные копии будут идти на диск RAID. Поскольку на самом деле у нас нет безопасного хранилища для всех наших дисков (если кто-то захочет, они могут разбить окна и забрать наши диски), я подумывал об использовании шифрования, может быть, что-то вроде дублирования (http://duplicity.nongnu.org/). Я обсуждал это с несколькими разработчиками, но они, кажется, убеждены, что шифрование - плохая идея, потому что один плохой бит может испортить весь блок. Однако я на самом деле не слышал ни о каких ужасных историях, где это происходило. Каково ваше мнение? Перевешивают ли преимущества риски, связанные с шифрованием?
Я делаю это, и у меня это работает (например, резервные копии работают нормально, и я сделал несколько восстановлений). Я использую бакулу, которая его поддерживает. На мой взгляд, указатели, как сделать это правильно, включают:
1) Ключ дешифрования хранится (в незашифрованном виде) на CD-R, а не в моей голове. Есть несколько копий CD-R, и ни одной из них у меня нет. Мне нужно делать восстановление только раз в несколько месяцев, и, честно говоря, я бы, вероятно, забыл пароль, который использовал нечасто. Это также означает, что моя безопасность не ограничивается длиной запоминающейся парольной фразы.
2) Программа резервного копирования уже должна это поддерживать; не начинайте взламывать это в свой любимый инструмент, потому что вы можете ошибиться и не узнаете, пока не станет жизненно важным, чтобы он работал (например, время восстановления).
3) Вы знаете о бит-флипах, но они могут испортить любой резервное копирование. Я чищу свои ленточные головки каждый раз, когда это запрашивает накопитель, чередую ленты каждые несколько лет и, прежде всего, сохраняю много инкрементальных лент. Если бит-флип действительно испортил вчерашний инкремент, я всегда могу вернуться в предыдущий день, что спасет большую часть моей задницы.
4) Задокументируйте процедуру восстановления. Шифрование всегда усложняет ситуацию, даже больше, если оно выполнено хорошо, и вам не нужно заново открывать колесо, когда вам нужно вернуть базу данных учетных записей. Я написал короткий README с множеством подробностей, которые очень специфичны для моей установки (настоящее пошаговое руководство, все имена путей явно указаны, и тому подобное), и он записан на те же компакт-диски, что и ключи дешифрования.
5) Прежде всего, много проверять. В любом случае вам следует регулярно проверять свои восстановления, но как только вы сделали что-то подобное, становится абсолютно важным, чтобы вы были уверены, что все работает так, как должно.
Плюсы, проистекающие из этой практики, включают отсутствие необходимости заботиться о том, что внешнее хранилище теряет одну или две ленты, что, будучи только людьми, время от времени происходит; легко уничтожить старые ленты (выбросить в мусорное ведро); и то, что все мои файловые системы зашифрованы на диске, больше не подорвано наличием стопки незашифрованных резервных копий в пожарном сейфе по соседству.
но они кажутся убежденными, что шифрование - плохая идея, потому что один плохой бит может испортить весь блок
Это не очень хорошая причина для отказа от шифрования. То же верно и для большинства сжатых резервных копий. Лучшим способом решения этой проблемы было бы использование отказоустойчивой файловой системы (отказоустойчивые форматы файлов очень малы на земле - в основном потому, что они не справляются с таким количеством сценариев сбоев, как отказоустойчивые файловые системы).
Как и в случае с любой другой резервной копией, вам необходимо убедиться, что у вас есть доступ к ресурсам, необходимым для восстановления данных, и периодически проверять / запускать тестовые восстановления.
Однако у вас гораздо больше шансов потерять ноутбук, чем сервер резервного копирования, поэтому, если ваши данные ценны, ваш первый порт захода должен решить, как защитить данные на ноутбуке. Это, вероятно, сильно повлияет на ваш выбор способа защиты резервной копии.
У них, как и у любых других, есть свои достоинства и недостатки. Проблема с бит-флипами, которые все портят1 можно обойти, правильно проверяя резервные копии и имея более одной копии (что в любом случае всегда является хорошей идеей - одна на месте для быстрого восстановления и одна за пределами сайта для целей аварийного восстановления).
Что касается преимуществ самого шифрования, то все сводится к тому, насколько плохо было бы, если бы резервные копии были украдены. У большинства компаний в наши дни достаточно критически важных данных, поэтому стоит хотя бы провести пилотный проект (чтобы узнать о практических вопросах управления этим) и провести анализ рентабельности инвестиций в целом.
Я использую rsync поверх ssh для резервного копирования 100 ГБ данных удаленного веб-сервера каждую ночь - требуется всего несколько минут, чтобы передать различия и синхронизировать локальное зеркало. Однако это зависит от того, что адресат не зашифрован.
После получения данных их можно заархивировать с помощью tar, сжать с помощью gzip (необязательно протестировать с помощью gzip -t), а затем, при желании, зашифровать и переименовать с указанием даты и сохранить в рейдовой системе. (Я обнаружил, что проще хранить все это, чем возиться с инкрементами).
Если на рейдовом диске используется зашифрованная файловая система, в дальнейшем шифровании резервных копий нет необходимости. Если диски украдены, они должны оставаться нечитаемыми, но если они забирают всю систему и ключ доступен где угодно, то это спорный вопрос.
Вы можете зашифровать файлы индивидуально, но их безопасность зависит от местоположения ключа.
Вы можете использовать ключ через https с удаленного веб-сервера как функцию исходного IP-адреса, таким образом, если система и резервные копии были украдены, вы все еще можете иметь некоторый контроль над ключом и можете вовремя отключить его.
Всегда храните несколько копий локально и удаленно.