Как сделать резервную копию распределенной файловой системы?
Примечание: это "теоретический" вопрос, так как у меня еще нет таких данных.
Если у вас есть распределенная файловая система, охватывающая десяток или более серверов, и объем данных, как вы выполняете резервное копирование этого? Локальные накопители на магнитной ленте недоступны, поскольку я арендую сервер и не имею физического доступа к ним. На мой взгляд, у меня просто должен быть резервный кластер, пропорциональный по размеру исходному кластеру. Параллельная отправка всех этих данных по сети, вероятно, приведет к насыщению и снижению пропускной способности. Но все резервные копии должны выполняться одновременно, поэтому резервное копирование с использованием циклического перебора не имеет смысла. Одним из способов решения этой проблемы было бы просто зарезервировать небольшую часть больших (в моем случае) накопителей, а оставшуюся - для вращения локальных снимков LVM. К сожалению, такого рода резервное копирование будет бесполезным, если сервер будет взломан. Есть ли другие варианты создания резервной копии на определенный момент времени, которая не убивает сеть?
[РЕДАКТИРОВАТЬ] РЕШЕНИЕ:
1) Реплицируйте весь набор данных в (почти) реальном времени на один большой локальный сервер резервного копирования, чтобы использование полосы пропускания и ввода-вывода распределялось в течение дня, а локальная полоса пропускания обычно была "свободной".
2) Создайте реальную резервную копию с этой машины и отправьте ее с сайта. Если у вас есть все данные вместе, должно быть легко сделать дифференциальное резервное копирование, которое экономит оплачиваемую пропускную способность.
2 ответа
Если вы обнаружите, что у вас есть больше данных, которые вы можете скопировать в своем окне резервного копирования - тогда вам нужно изучить репликацию всего набора данных с сайта в режиме реального времени или как можно ближе, используя отдельную инфраструктуру. (разные подсети, VLAN, разные каналы для наружной работы и т. д.)
Я бы использовал iSCSI, в частности, я бы использовал openfiler для репликации своих внутренних данных во внешний мир, а также другие полезности, которые вы можете получить с помощью openfiler.
Если это не удастся, я локально использую DRDB (при условии, что Linux) и скопировал это на несколько других серверов, а затем запустил с них мои резервные копии.
Лучший совет, который я могу дать людям, - разделить их критически важные данные и убедиться, что они скопированы в избыточное дисковое пространство, такое как SAN или, по крайней мере, NAS. Таким образом, вы можете в значительной степени развернуть любые локальные механизмы резервного копирования, которые вам нужны, зная, что вы в безопасности, потому что ваши важные данные в любом случае реплицируются вне офиса. Это боль, и руководство может поначалу не согласиться, но попросите их подсчитать, сколько вы потеряете во время простоя недели, вы обнаружите, что ваш бюджет чудесным образом увеличится!
Итак, серверы находятся в одном месте, хммм...
- Я бы добавил сервер в ферму в совместном расположении и получил бы копию всех данных DFS. Пропускная способность менее важна, поскольку она локальна. Этот сервер может затем обрабатывать сжатие и репликацию данных вне сайта.
- Затем я бы использовал этот сервер с собственной пропускной способностью для репликации на дополнительный сайт. Существуют "облачные" решения, которые будут реплицировать только изменения уровня битов. Пропускная способность сохраняется путем сжатия отправленных данных. Помимо сжатия, данные обычно шифруются.
Это решение становится все более распространенной практикой, и растет число поставщиков, предоставляющих программное обеспечение и хранилище для резервного копирования. Работа с ТБ для первоначальной покупки резервной копии обычно означает большую рыночную власть.
Эта идея применима как для Linux, так и для Windows. Конкретное программное обеспечение будет зависеть больше от вашего бюджета и ОС, которую вы используете.
Другие вещи для рассмотрения. Ваши общие данные могут быть 10 ТБ. Ежедневное изменение данных в традиционных резервных копиях может составлять 200 ГБ. Но изменение уровня битов может быть только 30 ГБ. ЕСЛИ эти данные сжимаются, вы можете уменьшить размер до 20 ГБ. Вам нужно будет знать свои данные, прежде чем вы сможете правильно планировать.