
Кто-нибудь хранит резервные копии vm на локальном сервере? У нас есть сервер HyperV с несколькими dev VM, и было упомянуто, как мы будем хранить резервные копии на локальном сервере, нотакжев удаленном месте. Идея в том, что локальное хранение резервных копий позволит быстро и легко восстановить виртуальные машины, а не получать их из удаленного места. Это, конечно, большая трата места, помимо всего прочего. Что еще в этом не так?
Спасибо
решение1
Это именно то, что мы делаем. Мы храним резервные копии D2D всех наших виртуальных машин; быстрое и простое восстановление для резервных копий за предыдущие несколько месяцев. Каждую неделю мы вывозим полную резервную копию ленты за пределы офиса для безопасного хранения.
Дисковый массив обошелся довольно дорого, но это меньше, чем один день простоя, что вполне возможно, если человек, хранящий резервные копии, заболел/уехал в отпуск/пропал без вести.
решение2
Для меня это имеет смысл. Что касается места, которое это займет, то, поскольку локальная копия не является основной резервной копией, почему бы просто не использовать внешние диски, которые стоят совсем недорого? Обычно я не рекомендую использовать жесткие диски для резервного копирования, но в этом сценарии нет причин не использовать их. Если/когда диск(и) выйдет из строя, просто создайте новую копию, используя резервную копию вне сайта.
Я использую похожий подход с нашими файлами с художественными работами (я работаю в типографии). Поскольку файлы очень большие, нам приходится периодически архивировать старые файлы, чтобы освободить немного свободного места. Эти архивы на лентах хранятся вне офиса. Поскольку художникам иногда требуется доступ к этим файлам, они также делают копии на DVD, что позволяет им легко получать доступ к файлам, не принося ленты обратно. Это беспроигрышная ситуация.
решение3
Лично я бы не хранил резервные копии на том же массиве или дисках, что и фактически используемые виртуальные машины. Храните резервные копии на сервере в том же физическом месте или на отдельном наборе дисков на сервере. Таким образом, у вас все еще будет действительно быстрый способ восстановления ваших виртуальных машин в случае сбоя диска или другого оборудования, которые являются наиболее распространенными.
Кроме того, как вы определили, вы также можете создавать резервные копии своих виртуальных машин в удаленном месте или на ленте, которые вы храните вне офиса, и использовать их для восстановления в случае полной потери машины, например, кражи, пожара, наводнения и т. д.
Поскольку вероятность этого гораздо ниже, чем вероятность отказа оборудования, вы можете обойтись менее частым резервным копированием виртуальных машин для удаленного/ленточного копирования данных и по-прежнему иметь быстрый метод восстановления для более чем 90% сбоев, которые могут произойти.
Надеюсь это поможет.
решение4
Мы делаем ежедневные резервные копии всех виртуальных машин на локальном диске (т. е. не на том же массиве хранения, где работают все виртуальные машины), с сохранением в течение недели. Раз в неделю мы копируем самую новую ежедневную резервную копию на ленту, которую мы храним вне офиса и ротируем еженедельно и ежемесячно, для максимального сохранения в течение 1 года.
Лучшей практикой являетсяПравило 3-2-1:
- Имейте как минимум три копии ваших данных (оригинал и две резервные копии).
- Сохраните копии на двух разных носителях (например, на диске и ленте).
- Сохраните одну резервную копию вне офиса.
Резервное копирование вне офиса, конечно, на случай аварийного восстановления, например, пожара или кражи, но локальная копия используется чаще всего. В конце концов, она быстрая (доступна локально) и содержит самые последние данные.
Дублирование кажется расточительным, но хранение обходится дешево, и обычно легко составить экономическое обоснование, если учесть потерю производительности.