Мне было поручено настроить систему резервного копирования для моего небольшого офиса (около 12 человек). Большая часть нашего производственного материала находится в облаке AWS, поэтому мне нужно создать резервную копию некоторых небольших офисных файлов / файлов разработки (сейчас менее 100 ГБ), а также наших рабочих виртуальных машин и разработки, которые составляют чуть менее 1T.
Мне просто нужно что-то надежное, удобное и простое. Мне комфортно с Linux, FreeBSD и, в некоторой степени, с Solaris 10, поэтому я склоняюсь к полноценному серверу, а не к системе устройств, таких как Openfiler или FreeNAS.
Я подумываю создать небольшой файловый сервер для общего хранилища и ночного резервного копирования виртуальных машин с последующим удаленным резервным копированием в сервис хранилища Amazon S3. Это будет обычное инкрементное резервное копирование каждую ночь и полное резервное копирование еженедельно.
У меня вопрос, является ли использование снимков ZFS, как локально, так и выгруженных на S3 через 'zfs send [-i]', жизнеспособным инструментом резервного копирования? Или мне следует полностью использовать Duplicity или какой-то другой метод?
Моментальные снимки ZFS на внутреннем файловом сервере / машине резервного копирования звучат как идеальный способ обеспечить быстрое и удобное восстановление данных, поэтому я, скорее всего, воспользуюсь этим для локальной избыточности. (Если вы, ребята, видите сценарии, в которых использование моментальных снимков ZFS будет хуже, чем более традиционное архивное резервное копирование, не стесняйтесь убедить меня.) Но достаточно ли гибки снимки, чтобы на них можно было опираться при восстановлении после потери моего сервера резервного копирования? Или мне лучше что-нибудь более традиционное? (не стесняйтесь рекомендовать бесплатные или коммерческие решения для резервного копирования, которые вам нравятся.)
Имейте в виду, что если вы не остановите виртуальные машины перед созданием моментального снимка файловой системы ZFS, на которой находятся их виртуальные жесткие диски, вы фактически будете делать резервную копию аварийной системы. Кроме того, чтобы восстановить один файл, который находится в моментальном снимке ZFS, вам нужно будет где-то загрузить весь моментальный снимок, предполагая наихудший случай, когда придется извлечь моментальный снимок, полученный из удаленного хранилища.
Хотя ZFS и моментальные снимки отлично подходят для случаев, когда «случилось что-то действительно плохое, и мне нужно, чтобы файловая система была такой же, как это было час, день неделю назад», они действительно не являются решением для резервного копирования в традиционном смысле. Я использовал ZFS и моментальные снимки вместе с другим программным обеспечением для резервного копирования, таким как bacula (www.bacula.org), с хорошими результатами. Очень удобно иметь возможность zfs отправлять моментальный снимок файловой системы на сервер резервного копирования, где он затем помещается в очередь на ленту, не влияя на ввод-вывод производственной системы.
Думаю, это возможно.
Рассмотрим середину пути между OpenFiler / FreeNas и полноценным Solaris. Бесплатная или коммерческая NexentaStor - хорошее решение для бытовой техники, или вы можете использовать простые (бесплатно) Nexenta Core если вы предпочитаете использовать сервер не только для хранения. Если вы пойдете по маршруту устройства, вы сможете запланировать свои моментальные снимки с любым желаемым интервалом (каждые x минут, часов, дней и т. Д.), И репликация будет довольно чистой. Вы можете использовать rsync (или rsync + ssh) или zfs send / receive + netcat или ssh для отправки в локальное или удаленное хранилище. Если вы используете репликацию на основе rsync, ваша цель не обязательно должна быть файловой системой ZFS. Это делает его легким выбором для вашего приложения.
Другое преимущество любого недавнего решения ZFS состоит в том, что вы можете использовать сжатие и / или дедупликацию, если ваша система хранения достаточно хорошо подходит с точки зрения ОЗУ и ЦП. Это творит чудеса для определенных типов виртуальных машин и довольно прозрачно для пользователей.
Если бы я планировал ваше решение для резервного копирования, я бы обязательно имел локальные моментальные снимки на ежечасном накоплении для ежедневных / еженедельных / ежемесячных снимков, а также возможность отправки ежедневных снимков на вторую локальную систему или удаленную систему. Я бы по-прежнему дополнял это резервным копированием на основе агента в конкретных виртуальных машинах (например, сброс BackupExec на выделенный сервер резервного копирования + ленточный накопитель или rsync наиболее важных данных в другое место). С резервными копиями вам нужны варианты и гибкость для восстановления.
Также см. Следующее:
Рекомендации VMware NAS / iSCSI - небольшая организация
http://www.anandtech.com/show/3963/zfs-building-testing-and-benchmarking