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