Копирование vhd диска на работающей машине
Моментальные снимки: сложно о простом
Наверняка многие знакомы с достаточно полезной функцией многих продуктов виртуализации – моментальными снимками, в простонародье – «снапшоты» (snapshots). Снапшот виртуальной машины – это как сохранение в игре: в случае, если где-то сильно накосячил (патч Бармина применил, например) – можно вернуться назад и повторить все заново. В этой статье я попытаюсь более-менее подробно рассказать о работе моментальных снимках и о некоторых нюансах их применения. В статье речь пойдет о Microsoft Hyper-V, но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).
Прежде, чем продолжать – вспомним, из каких компонентов состоит виртуальная машина:
Файл конфигурации – основа виртуальной машины, хранит все настройки, касающиеся виртуалки. Представляет собой XML-файл, имеющий, как ни странно, расширение XML. В VirtualPC/Virtual Server этот файл имел расширение VMC.
Файл виртуального диска. Обычно в качестве жесткого диска виртуальные машины используют специальные файлы-образы, имеющие расширение VHD. Этот формат, изначально разработанный фирмой Connectix, после приобретения ее корпорацией Microsoft стал использоваться в продуктах виртуализации, и не только в них: в частности, они используются в Microsoft Software iSCSI Target, а в ОС Windows 7 и Windows Server 2008 R2 с VHD-дисками можно работать на уровне ОС, вплоть до загрузки с них самой операционки.
Дифференциальные диски – основа технологии снапшотов. При создании снапшота запись в VHD-файл прекращается, и все последующие изменения записываются в отдельный файл, имеющий расширение VHD.
Сохранение состояния (Save State) – одна из полезных функций системы виртуализации. При сохранении состояния все содержимое памяти виртуальной машины, регистров процессора и т.д. сохраняется в специальные файлы, и виртуалка переходит в состояние «Выключено». После этого можно делать все что угодно, вплоть до перезагрузки хостовой машины, а потом снова запустить виртуалку – и она будет работать, как ни в чем не бывало, ровно в том же состоянии, в каком она была до сохранения. Примерно так же работает функция Hibernate в Microsoft Windows с единственным лишь отличием – сохранение состояния происходит на уровне самой виртуальной машины, а не на уровне гостевой ОС. В VirtualPC и Virtual Server для сохранения содержимого памяти использовался файл с расширением VSV, в Hyper-V же их стало аж целых два – BIN и VSV.
Файл экспорта. Если виртуальную машину Hyper-V нужно склонировать, или же перенести на другой хост – необходимо произвести операцию экспорта, а затем импорта. При экспорте конфигурационный XML-файл преобразуется в файл с расширением EXP. В VirtualPC и Virtual Server для этого достаточно просто скопировать файлы виртуальной машины, а в Hyper-V придумали импорт/экспорт – как они сами говорят, в целях безопасности.
Различают два типа моментальных снимков: онлайновый и оффлайновый. Онлайновым называют снапшот, сделанный на виртуальной машине с запущенной гостевой ОС. Соответственно, если виртуальная машина была в состоянии «выключено» — то снапшот будет называться оффлайновым. Для пользователя нет абсолютно никаких различий между онлайновыми и оффлайновыми снапшотами. Различаются они только по составу файлов, потому что при создании снапшота на запущенной виртуалке происходит операция Save State, и данные Save State включаются в состав снапшота
- Копия файла конфигурации
- Дифференциальный диск AVHD
- Файлы Save State – BIN+VSV
- Копия файла конфигурации
- Дифференциальный диск AVHD
Что можно и что нельзя делать с моментальными снимками?
Как уже было сказано, снапшоты виртуальных машин – это то же самое, что и сохранение в игре. И единственное их назначение – обеспечение точки возврата на случай возможных ошибок. Снапшоты – это не бэкап, и использовать их для аварийного восстановления не получится. Использовать моментальные снимки в production-среде не рекомендуется, потому что это может привести к падению производительности, почему это так – будет понятно далее из статьи. Если необходимо часто создавать резервные копии для защиты от ошибок пользователей – необходимо использовать другие средства, к примеру – инкрементные бэкапы или журналы транзакций, если речь идет о базах данных.
Помимо этого, необходимо помнить, что управлять снапшотами можно и нужно только через стандартные средства Hyper-V (оснастка MMC Hyper-V Manager, WMI-провайдеры, командлеты PowerShell) и сторонний софт, использующий такие средства – например Microsoft SystemCenter Virtual Machine Manager.
- Apply – возвратиться к точке создания снапшота, при этом все изменения, произошедшие с момента создания снапшота и до настоящего времени будут потеряны.
- Delete – точка возврата удалится, а все внесенные изменения сохранятся на веки вечные.
- Во-первых, удаляется копия файла конфигурации, и сам снапшот исчезает из списка.
- Если в данный момент виртуальная машина запущена – AVHD, связанный с этим снапшотом остается, и запись в него продолжается.
- Как только виртуальная машина останавливается (шатдаун или перезагрузка) – все данные из AVHD записываются в предыдущий AVHD, или в VHD, если мы удаляем первый снапшот, а сам AVHD удаляется. Эта операция называется «Объединение» (Merging). Операция объединения может занять определенное время (в зависимости от объемов данных), в течение которого запустить виртуалку нельзя.
Ну и теперь скажу несколько слов в заключение.
Во-первых – как я уже говорил, нужно помнить про «Delete means Apply, Apply means Delete», и думать перед нажатием кнопки, дабы не потерять ничего.
Во-вторых, если виртуальная машина содержит онлайновые снапшоты – ее крайне не рекомендуется экспортировать и переносить на другой сервер. Дело в том, что онлайновый снапшот содержит состояние регистров процессора и содержимое памяти, и применение такого снапшота в другом аппаратном окружении может привести к краху гостевой ОС.
В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде. Наверняка вам известно, что для продакшна рекомендуется использовать виртуальные диски фиксированного размера – для того, чтобы избавиться от фрагментации VHD-файла. Создавая же снапшоты, мы искусственно делим наш виртуальный диск на отдельные файлы – VHD и множество AVHD. На высоконагруженных системах это может привести к некоторому падению производительности. Кроме этого, при удалении снапшотов происходит операция объединения, которая тоже может сказаться на общей производительности системы, а к тому же может повысить время простоя при перезагрузках виртуальной машины. К примеру, если вы удалили один или несколько снапшотов на виртуальной машине, а потом потребовалось ее перезагрузить (к примеру – при установке апдейтов), то загрузка ОС не начнется, пока не завершится полностью операция объединения. Поэтому снапшоты можно использовать перед вводом в продакшн, для экономии времени при установке ПО и начальной настройке. После этого все снапшоты нужно удалить, дождаться окончания объединения, и только затем вводить в продакшн.
Еще один небольшой момент: в настройках Hyper-V можно задавать отдельно путь для размещения файлов виртуальных машин и путь для размещения VHD. По умолчанию и то и другое хранится на диске C:. Если для хранения VHD планируется использовать, к примеру, высокоскоростной RAID-массив – необходимо хранить на нем не только VHD, но и файлы виртуальных машин. Дело в том, что при создании снапшотов файлы AVHD будут храниться именно в том месте, которое было выбрано для хранения виртуальных машин. И может получиться так, что сам VHD будет храниться на отдельном дисковом массиве, а куча AVHD будет на диске С:, что не есть хорошо.
Если хаброобщественность не будет возражать – я могу дать ссылки на другие свои скринкасты и статьи про Hyper-V, дабы не кросспостить и не копипастить. Надеюсь, кого-то моя статья заинтересовала, в любом случае – спасибо заранее.
Хочу поделиться с вами опытом о том, что у меня отняло море времени — о бэкапах виртуальных машин и обычных компьютеров. Как сделать дешево и красиво.
Пожалуй, начну с того, что если вы хотите бэкапы на VMWare, то готовьтесь платить. Бесплатный VMWare — это бесплатно до тех, пока речь не идет о миграциях, бэкапах и тому подобное. На этом месте можно начать бесконечный холивар, но без моего участия. Мои повествования будут только о Hyper-V на Windows Server 2012R2. Хотя часть статьи можно применить и к VMWare, но, вероятно, будут подводные камни.
Бэкапить на Hyper-V мы можем бесплатно, а точнее, теми средствами Windows, за которые мы уже заплатили, приобретая лицензии Windows Server. Для удобства работы с нашими бэкапами (к тому же за это мы тоже заплатили) будем использовать WDS и дедупликацию (может и групповые политики).
1. Бэкап изнутри виртуальных машин
5. Групповые политики
Вот тут можно долго и по-разному реализовывать установку скрипта бэкапа с помощью GPO. Но хотелось бы обратить внимание на важные моменты:
Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но многие из них устарели. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.
Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.
Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.
Настраиваем миграцию для кластеризованного сценария
Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:
-
SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду.
Чтобы трафик живой миграции использовался только на определенной сети, также оставим отдельную сеть в настройках Failover Cluster:
Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V.
19.03.2019
itpro
Hyper-V, Резервное копирование
комментариев 17
Несмотря на то, что среда Hyper-V предоставляет довольно много технологий обеспечения высокой доступности и отказоустойчивости виртуальных машин (таких как кластера, Live Migration, репликация, и т.д.), администратору необходимо думать о классическом резервном копировании виртуальных машин. Все эти технологии позволяют минимизировать время недоступности ВМ в различных сценариях, но не обеспечивают возможность восстановления в случаях различных форс мажоров, таких как природные катаклизмы, ошибки персонала, хакерские или вирусные атаки, атаки конкурентов и подобные сценарии. В этой статье я постараюсь рассмотреть основные требования, которые предъявляются к системам резервного копирования Hyper-V, стратегии резервного копирования и возможности бесплатных и коммерческих продуктов резервного копирования.
Вы можете создавать резервные копии виртуальных машин, запущенных на хосте Hyper-V, с помощью встроенного Windows Server Backup (или скриптов на его основе, запускаемых через wbadmin), бесплатных или коммерческих продуктов. Всех эти способ объединяет то, что в основе резервного копирования виртуальных машин Hyper-V лежит технология снапшотов (или снимков). В снимке хранится как состояние виртуальных дисков, так и содержимое памяти и настройки виртуальной машины. Т.е. снапшот представляет собой состояние виртуальной машин на какой-то момент времени.
Экспорт/импорт ВМ из консоли Hyper-V Manager
Сначала нужно экспортировать ВМ в отдельный каталог.
Запустите консоль Hyper-V manager, выберите ВМ и в контекстном меню выберите Export.
Начиная с версии Hyper-V в Windows Server 2012 R2 (в том числе в Free Hyper-V Server) вы можете экспортировать даже запущенные виртуальные машины без их остановки.
Укажите каталог, в который нужно экспортировать виртуальную машину.
Статус экспорта ВМ будет отображен в строке состояния ВМ в консоли Hyper-V.
Начиная с Hyper-V в Windows Server 2012 R2 вы можете экспортировать конкретный снимок (checkpoint) виртуальной машины. Для этого достаточно выбрать нужны снимок в дереве Checkpoints и выбрать Export.
Чтобы импортировать ВМ щелкните в консоли Hyper-V Manager по имени хоста и выберите Import Virtual Machine.
Затем нужно указать путь к каталогу, в котором находятся папки с файлами импортируемой ВМ. При импорте ВМ в Hyper-V предлагается 3 варианта регистрации ВМ на хосте:
- Register the virtual machine in-place (use the existing unique ID) —зарегистрировать ВМ в каталоге с импортируемыми файлами, ID ВМ сохраняется;
- Restore the virtual machine (use the existing unique ID) — скопировать файлы ВМ в другой каталог, сохранить исходный идентификатор ВМ;
- Copy the virtual machine (create a new unique ID) — скопировать ВМ в другую каталог и сгенерировать новый ID.
У каждой ВМ на хосте Hyper-V есть идентификатор ID, который должен быть уникальным в рамках хоста. Если вы импортируете, клонируете ВМ на другой хост, ID ВМ менять не обязательно.
Если вы попробуете импортировать ВМ с дублирующим ID, появится ошибка:
Чтобы создать клон ВМ с новым ID мы выбрали 3 вариант. Мастер предложит указать в каких каталогах нужно разместить файлы ВМ. По умолчанию, используются каталоги, заданные в настройках хоста Hyper-V.
Затем укажите каталог для хранения виртуальных дисков vhdx ВМ.
После этого новая клонированная виртуальная машина появится в консоли Hyper-V.
1.2. Бэкап с историей предыдущих снимков
На данный момент, мы сделали бэкап образов виртуальных машин. Но это же у нас бэкап снимков только сегодняшнего дня. Завтра он будет совершенно другой… Но что будет, если бэкапить бэкапы? Да и ещё по-настоящему инкрементально. Так и поступим.
Но мне было этого недостаточно и я сделал так:
Скрипт подключает виртуальный диск из сети. После бэкапа подобный же скрипт отключает диск. ОС помнит, что у диска определена буква E. Но не дай бог подсунуть чужой диск с той же буквой E, бэкап отработает уже по полной (не инкрементально и на чужой диск). Имейте это в виду и используйте, букву, ближе к концу алфавита (X, Y, Z)…
Замечу сразу, если бэкап сегодняшний будет производиться параллельно с бэкапом с историей, то получим в итоге бэкап, который невозможно поднять.
Чтобы достать бэкап предыдущих дней можно воспользоваться интерфейсом (GUI) сервера, на котором производятся бэкапы с историей. Более того, все запуски команды wbadmin в консоли Windows знает и помнит. Служба восстановления даст возможность вам выбрать нужный архив в бэкапах с историей.
Клонирование виртуальных машин Hyper-V через Windows Admin Center
Возможно клонировать ВМ Hyper-V напрямую без промежуточного экспорта/импорта появилась в Windows Admin Center v2009.
Запустите WAC, выберите раздел Virtual Machines, выберите ВМ -> Manage -> Clone.
Затем нужно указать имя новой ВМ и каталог, в который нужно поместить ее файлы.
Обратите внимание, что мастере клонирования есть опция “I have already run sysprep on my VM”. Если вы не выполнили генерализацию образа с помощью Sysprep, и не включили эту опцию, Hyper-V создаст снапшот исходной ВМ, выполните ее Sysprep и склонирует в новую (исходная ВМ будет несколько раз перезагружена и не доступна для работы). После этого исходная ВМ будет возвращена в первоначальное состояние, а снапшот удален.
Дождитесь окончания клонирования ВМ. Новой ВМ автоматически будет присвоен новый ID.
Предыдущая статья Следующая статья
Включаем поддержку SR-IOV для виртуальных машин Hyper-V
Низкая скорость сети на хосте Hyper-V с Windows Server 2019
Установка VMWare ESXi в виртуальную машину Windows Hyper-V
Маршрутизация между разными IP подсетями в Hyper-V
А какие есть бесплатные способы сделать клон ВМ из ESXi в Hyper-V?
Из приличных был StarWind V2V Converter, вроде это функционал там бесплатные. можно еще тулзой disk2vhd
«зарегистрировать ВМ по хранения файлов» — что это?
Отсуствие грамотного редактора для вычитки 🙂
речь про «по месту хранения файлов»
Copy и GenerateNewId вместе. Не ошибка?
Очень интересует последний способ, спасибо за него! Я поставил Windows Admin Center, она отлично встала на Windows Server 2022, я попробовал клонировать Windows 10 (заведено 2 юзера, оба админы).
Вот какую ошибку получаю:
Подробная информация об уведомлении
Ошибка
Не удалось клонировать виртуальную машину
00:43:25
Источник
Перейти в Виртуальные машины
Тип
Ошибка
Хотелось бы поинтересоваться, как можно победить следующую проблему. Из-за расплодившихся снапшотов, на физическом диске закончилось место и виртуалка не запустилась. Перенес один из виртуальных дисков на другой физический диск. Система запустилась, преждевременно спросив где тот самый диск. Теперь все работает, но место может закончиться.
Клонировать систему не дает, перенести не дает, и удалить снапшоты тоже не дает.
Подскажите как решить проблему? Можно ли скопировать всё на внешний диск и путем подмены букв дисков запустить виртуалку? И если можно, то как отключить службу hyper-v на время подмены букв?
Спасибо, надеюсь на ответ
Вот так не дает переместить файлы ВМ?
Move-VMStorage "VMname" -DestinationStoragePath "FullPathtothenewfolder"
Я так понимаю эту команду можно запустить при работающей машине? Или желательно отключить?
Ошибка выходит
Move-VMStorage: Не удалось выполнить операцию, так как файл не найден.
Move-VMStorage позволяет делать онлайн миграцию. другая проблема в том, что если виртуальный диск во времея миграции нагружен из гостевой ВМ, это может занять дополнительное время иил просто не хватит места для хранения изменнеия.
файл не найден — проверьте путь к файлам
Почему не видит работающую машину?
Вспоминаем матчасть
Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:
Чем больше оперативной памяти у ВМ и чем интенсивнее она изменяется, тем дольше будет переезд. Поэтому трафик живой миграции требует хорошего канала и тщательной настройки.
По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.
Помимо этого есть второй вид Live Migration, живая миграция в режиме «ничего общего» (Shared-Nothing Live Migration). Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.
Разберем основные нюансы по настройке интерфейсов.
Клонирование ВМ через экспорт/импорт в Hyper-V с помощью PowerShell
Рассмотрим, как клонировать виртуальную машину Hyper-V через импорт/экспорт из консоли PowerShell.
Для экспорта ВМ воспользуйтесь такой командой:
Export-VM -Name win10 -Path 'C:\VHD\export'
Если вы хотите экспортировать запущенную ВМ, вы можете использовать параметр CaptuteLiveState, в котором определяется как нужно копировать оперативную память ВМ. Доступны три опции
- CaptureSavedState – экспортировать оперативную память (по-умолчанию);
- CaptureDataConsistentState – экспортировать состояние ВМ из Production checkpoint;
- CaptureCrashConsistentState – не сохранять содержимое памяти.
Export-VM -Name win10 -Path 'C:\VHD\export' -CaptureLiveState CaptureCrashConsistentState
Если вы хотите экспортировать состояние ВМ в определеном снимке, нужно указать его имя.
Сначала выведите список снимков для указанной ВМ:
Get-VMSnapshot -VMName win10
Затем выполните экспорт нужного снимка по его имени:
Export-VMSnapshot -Name “win10 - (2/17/2021 - 9:52:20 PM) Standard” -VMName win10 -Path 'C:\VHD\export'
После завершения экспорта ВМ вы можете импортировать ее. Если нужно зарегистрировать ВМ по месту хранения файлов, выполните команду:
Import-VM -Path "C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx"
В параметре Path указываем расположение vmcx файла конфигурации ВМ (формат vmcx заменил XML формат конфигурационных файлов ВМ в Hyper-V Server 2016). Для копирования ВМ в другой каталог с тем же ID используйте параметр Copy. Чтобы сгенерировать нового идентификатор ВМ, используйте параметр GenerateNewId:
Import-VM -Path "C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx" -VhdDestinationPath "C:\VHD\win10_2" -VirtualMachinePath "C:\VHD\win10_2"
В параметре VhdDestinationPath указывается каталог, куда нужно скопировать VHDX файлы ВМ, а в параметре VirtualMachinePath — каталог конфигурационных файлов ВМ. Если эти параметры не задать, файлы ВМ будут скопированы в дефолтный каталог, указанный в настройках хоста Hyper-V (C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\).
Также можно указать каталоги для хранения чекпоинтов ( SnapshotFilePath ) и файла подкачки ( SmartPagingFilePath ).
Обратите внимание, что клонированная ВМ появилась в консоли Hyper-V с оригинальным именем. Переименуем новую ВМ, но сначала нужно получить ее ID:
get-vm | select VMNAME,VMId
Как вы видите в консоли есть две ВМ с одинаковым именем и разными ID. Нужно переименовать ВМ с ID, который отличается от ID импортируемой ВМ. Скопируйте ID новой ВМ и переименуйте ее:
Затем для удобства можно переименовать виртуальный жесткий диск.
Get-VHD -VMId 24ad8934-f650-46f6-9caa-2a3b79b79bd5| Select Path | Rename-Item -NewName win10_2.vhdx
Remove-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerLocation 0 -ControllerNumber 0
Add-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path "C:\VHD\win10_2\win10_2.vhdx"
Изменим MAC адрес виртуального адаптера (можно указать новый статический MAC или настроить динамическое получение MAC адреса).
Set-VMNetworkAdapter -VMName win10_2 -DynamicMacAddress
Start-VM -Name win10_2
Прежде, чем подключить новую ВМ в сеть, желательно переименовать ее и изменить IP адрес на новый (если используется DHCP адресация, этот шаг можно пропустить). В данном случае мы можем подключиться к новой ВМ через PowerShell Direct с помощью командлета Invoke-Command или Enter-PSSession:
Enter-PSSession -ComputerName win10_2 -Credential (Get-Credential)
Rename-Computer win10_2
Remove-NetIPAddress -InterfaceAlias “Ethernet” -AddressFamily IPV4
New-NetIPAddress -IPAddress 192.168.31.50 -InterfaceAlias “Ethernet” -AddressFamily IPv4 -PrefixLength 24
Restart-Computer
3. Восстановление бэкапа и WDS
А теперь, по-моему мнению, самая полезная часть этой статьи про бэкапы.
WDS — это Windows Deployment Services (службы развертывания Windows) и часть функционала Windows Server 2012R2. Раньше эта служба называлась RIS, но я с ней не сталкивался. Вообщем, суть WDS проста. Прописались в DHCP (автоматически для DHCP Windows Server) в виде отдельных параметров и далее загружаем на компьютер по сети (такая настройка BIOS компьютера для загрузки по сети) через TFTP загрузчик WDS. Далее загрузчик WDS позволяет выбрать из доступных на ней образов «загрузчиков» Windows. Загрузчики бывают разные — это и образы загрузчиков установщика, и PE, и RE образы. Для загрузчика установщика ещё нужны образы самих Windows в WDS, но это в случае, если нужно установить Windows по сети. Нас интересуют RE образы, которые позволяют поднять машину из бэкапа.
Как и что работает в WDS подробно объяснять не буду. Но вот важные заметки:
- Если у вас загрузчик RE загружается на Hyper-V виртуальной машине по сети, но не работает клавиатура в ней. Поздравляю, ваш RE образ для WinXP или древнее и не знает о существовании Hyper-V драйверов.
- Если у вас система начинает восстанавливать бэкап, но останавливается. Удалите все разделы на жестком (на котором восстанавливается бэкап) и попробуйте заново. Только не забывайте, что бэкап может быть битый и после удаления всех разделов на жестком у вас может ничего не остаться от старой информации.
- Если бэкап с загрузкой UEFI, а вы хотите восстановить на комп без UEFI, то не стоит тратить время. Скорее всего развернуть бэкап не получится.
- Бэкап с загрузкой UEFI и разделами GPT можно восстанавливать на машины с другим процессором / материнкой, а вот с разделами MBR формата и с загрузкой обычного BIOS на другой машине развернуть вряд ли получится. Ну у меня точно не получалось.
- Если бэкап пытаться развернуть на диск с меньшим объемом, то сделать это не получится. Даже если диск в бэкапе был почти пуст. В этом случае помогает восстановление на виртуальную машину с динамическим диском. Далее уменьшение этого диска и создание нового бэкапа. Но такое можно только с загрузчиком UEFI в бэкапе (почему, читаем предыдущий пункт).
- Стоит перед восстановлением бэкапа отключить лишние диски, чтобы не затереть информацию на них.
Задаем настройки протоколов
-
Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор:
-
Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами.
Возможность использовать этот протокол появилась в Windows Server 2016. SMB по умолчанию отдает трафик в несколько портов (SMB Multi-channel). Также он прекрасно работает с RDMA – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров.
Начиная с Windows Server 2016, службы работают в контексте NETWORK SERVICE, который не может имперсонироваться в AD. Так что в этом случае выбираем неограниченное делегирование (Unconstrained Delegation), но учитываем, что это довольно небезопасно:
Так мы совершим меньше действий при передаче трафика и не потратим лишнее время на шифрование. В случае с кластерами оно может нам понадобиться.
Эти же настройки в более модном Windows Admin Center:
2. Бэкап файлов vhdx виртуальных машин
Производится легко и непринужденно:
Но с некоторыми особенностями. Эта команда должна выполняться в PowerShell и с предварительным получением списка виртуальных машин в переменную. За подробным примером обращаемся в Google.
Бэкап виртуальных машин в Windows Server 2012 R2 идет с помощью моментальных снимков Hyper-V. Также замечу, что происходят приостановка работы виртуальных машин, если на них ядро Linux или отсутствуют Hyper-V драйвера. Я лично отказался бэкапить виртуальные машины таким способом. Причина в том, что на Windows Server 2012 (не R2) требовалось останавливать виртуальные машины до бекапа. Да и сейчас на Windows Server 2012 R2 приостановки Linux меня не устраивают, когда есть первый неплохой способ бэкапа. (в комментариях к данной статье есть замечание). После очередного обновления в Windows Server 2012 R2 бэкап любых виртуальных машин проходит без приостановок. ОС Linux также можно бэкапить «изнутри» с помощь Dump (CentOS, Ubuntu), но это отдельная тема с puppet'ами и другим ПО в моем случае.
Сторонние средства резервного копирования Hyper-V
При большом количестве хостов Hyper-V и виртуальных машин, использовать встроенный Windows Server Backup нереально. Вам в любом случае придется выбирать одно из сторонних решений. Однозначно говорить, что тот или иной продукт будет идеальным решением для резервного копирования Hyper-V нельзя, слишком много нюансов нужно учесть. Это и количество хостов, лицензионные ограничения, необходимый функционал, архитектура сети и т.д.
На рынке представлено большое количество коммерческих и бесплатных продуктов для резервного копирования, и запутаться в них очень сложно. Обычно для оценки лидеров ниши используется магический квадрант Gartner. Я нашел такую картинку, характеризующие основных игроков и лидеров на рынке резервного копирования для дата-центров.
Как вы видите, Гартнер среди лидеров решений по резервному копированию выделяет компании и продукты:
- Actifio
- Commvault
- Dell EMC
- IBM
- Rubrik
- Veeam
- Veritas Technologies (Symantec — Veritas Backup Exec)
- Acronis (Veritas Backup Exec)
- Symantec (Veritas Backup Exec)
В рамках одной статьи оценить и сравнить все продукты довольно сложно, поэтому попробуем рассмотреть возможности нескольких программ – лидеров рынка по резервному копированию Hyper-V.
- Veritas Backup Exec
- Commvault Backup
- Veeam Backup
- Acronis Backup
Я составил небольшую сравнительную таблицу с интересными мне возможностями этих средств резервного копирования (рассматривается функционал версий, актуальных на момент написания статьи).
Функционал/ Продукт | Veritas Backup Exec 20.2 | Commvault Backup and Recovery 11 | Veeam Backup & Replication 9.5 | Acronis Backup 12.5 |
Резервное копирование файловых систем | Windows / Linux | Windows / Linux / IBM AIX / HP-UX | Windows / Linux / IBM AIX / HP-UX. Агенты для физических систем автономны, не поддерживают совместное использование хранилищ групповые политики | Windows / Linux |
Передача резервных копий дисковых массивов по NDMP | + Поддержка NDMP v4+. Список поддерживаемых хранилищ есть на сайте veritas. Не поддерживается инкрементальное и дифференциально копирование, бэкап только LUN целиком и нельзя восстановить отдельные файлы. | + Поддержка прямого резервного копирования данных с файловых устройств NAS. На сайте Commvault есть список поддерживаемых версий файловых систем разных производителей. При использовании этого типа резервного копирования данные отправляются напрямую с NAS через MediaAgent (прокси сервер) на устройство хранения, минуя управляющий сервер CommServe. Поддержка бэкапов отдельных vmdk файлов. | + Поддержка NDMP (v4 и выше) появилась относительно недавно. Поддерживается бэкап только LUN целиком. Поддерживается до 10 точек восстановления (на NetApp до 30). | — |
Передача моментальных снимков ВМ по SAN | + На сайте Veritas в секции Hardware Compatibility List представлен список совместимых HBA адаптеров, SAN свичей | + Поддерживается бэкап по SAN как для ESXi так и для Hyper-V хостов | + Необходимо дополнительная физическая машина с ролью выделенного прокси сервера Veeam, подключенного к той же сети SAN и презентованными LUN | Поддержка моментальных снимков только в VMware vSphere для хранилищ NetApp с Data ONTAP |
Репликация резервных копий в несколько хранилищ (в том числе на удаленную площадку) | + | + | + | + |
Поддержка гранулярного восстановления приложений и БД | Microsoft SQL / Exchange / AD | Microsoft SQL / Exchange / AD / Domino / DB2 / MySQL / Oracle | Microsoft SQL / Exchange / AD / Oracle (только для виртуализированных приложений, не поддерживается на физических системах) | Microsoft SQL / Exchange / AD |
Управление аппаратными снимками СХД | + | + (IntelliSnap) | + (список поддерживаемых вендоров и моделей СХД ест ь на сайте, для некоторых необходима установка отдельного модуля интеграции) | + |
Лицензирование для сред виртуализации | Хост / сокет / Объем данных | Сокет / Объем данных | На сокет (процессор) | На хост |
Стоимость 1 лицензии (ориентировано) | От 85 тыс. р. | 190 тыс. р. | 70 тыс. р. (редакция Standard), 200 тыс. р. (редакция Enterprise Plus) | 45 тыс. р. (редакция Standard), 95 тыс. р. (редакция Advanced) |
Как вы видите, функционал и стоимость лицензий для каждого продукта довольно сильно отличается. Поэтому перед принятием решений о выборе того или иного решения стоит составить список требований к продукту резервного копирования Hyper-V, список имеющегося оборудования и необходимый функционал. У большинства известных продуктов резервного копирования есть бесплатные версии с некоторыми ограничениями, обычно их достаточно для оценки функционала.
27.07.2021
itpro
Hyper-V, PowerShell, Windows Server 2016, Виртуализация
комментариев 14
В Hyper-V в отличии от VMWare нет встроенной функции клонирования виртуальной машины (клонирование есть только в Virtual Machine Manager). Чтобы создать полную копию существующей ВМ придется использовать функцию импорта/экспорта. В этой статье мы рассмотрим, как клонировать виртуальную машину в Hyper-V через импорт/экспорт через графический интерфейс Hyper-V Manager, PowerShell и Windows Admin Center (WAC).
При клонировании виртуальных машин с Windows не забывайте о том, что после клонирования ВМ у ее копии будет такой же SID. Для сброса SID нужно использовать утилиту sysprep. Если вы создали эталонный образ Windows, то перед клонированием на нем нужно выполнить команду:
%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe
ВМ будет выключена и при следующей загрузке как оригинальной ВМ, так и ее клона для Windows будет сгенерирован новый SID. Также нежелательно клонировать ВМ, включенные в домен Active Directory.
4. Особенности дедупликации
Можно дедуплицировать работающие виртуальные машины. Можно дедуплицировать бэкапы сегодняшнего дня и можно дедуплицировать бэкапы с историей. Все это дает большой положительный плюс к объему жестких дисков (как для HDD, так и SSD). Но не стоит забывать о некоторых вещах:
- Если дедупликация будет работать с дисками с объемом более чем 1 ТБ, то оптимизатор дедупликации будет использовать очень много памяти.
- Если дедупликация будет работать с сжатыми данными, но с объемом сжатого более чем 10 ТБ, то длительность работы оптимизатора дедупликации будет слишком большим. Такое может получиться, если просто копировать данные ежедневно на дедуплицированный диск в разные папки.
- Бэкапы на HDD хранить можно и даже нужно, а вот рабочие виртуальные машины хранить на HDD в количестве больше 5-10 не стоит. К дедупликации это относиться с той лишь стороны, что дедупликация таких рабочих виртуальных машин сведет производительность HDD в ноль.
Разбираемся с конфигурацией сети
Сетевая оптимизация Hyper-V – это крайне дискуссионная тема в сообществе и безграничное поле для экспериментов (предела совершенству в нем нет по определению). Так что перед пошаговой настройкой сети разберемся, как технологии изменились за последнее время и как можно это использовать.
Как было раньше. Старые мануалы по переносу ВМ Hyper-V описывают сценарии с использованием технологии тиминга Load Balancing/Fail Over (LBFO). LBFO позволяла группировать физические сетевые адаптеры и создавать поверх них интерфейсы. Но были и минусы, например: не было поддержки RDMA, нельзя было выяснить, через какой порт тима будет идти трафик. А поскольку трафик живой миграции требует довольно жирного канала, это превращалось в проблему, когда все сетевые ворклоады ломились в один физический порт.
Как сейчас. В Windows Server 2019 даже нельзя создать виртуальный свитч поверх LBFO Team. Единственным поддерживаемым решением для объединения портов сетевой карты в Hyper-V остался Switch Embedded Team (SET).
SET агрегирует адаптеры, как и vSwitch у ESXi. Физические сетевые порты становятся патч-кордом для разных типов трафика (в том числе для ВМ), а поверх них нарезаются виртуальные интерфейсы.
Тут нужно добавить, что в типах гипервизоров есть небольшой рассинхрон. Англоязычные авторы считают, что есть только 2 типа, но на самом деле их 3 (подробно мы с коллегами описывали их в этом посте). Когда-то гипервизоры ESX были гибридного типа (1+). Это был такой модернизированный Red Hat c ролью гипервизора. VMware ушла от этого в vSphere 4.1 и стала честным гипервизором типа 1 (bare-metal).
Microsoft взяла опыт VMware на вооружение и реализовала Switch Embedded Team в Windows Server 2016. Эта схема показывает большую производительность и гибкость в управлении трафиком в рамках тиминга.
В новых версиях SET позволяет создавать разные виртуальные интерфейсы для разных нагрузок поверх группы физических интерфейсов. По сути, это виртуальные сетевые адаптеры корневого раздела, которыми мы можем управлять наподобие виртуальных адаптеров ВМ.
Как это влияет на процесс настройки. В Hyper-V, помимо менеджмент-интерфейса, мы обычно создаем интерфейсы для живой миграции и интерфейсы для CSV-трафика кластера. Для этого нам нужно знать количество сетевых портов, входящих в SET, – именно столько виртуальных интерфейсов нужно будет создать. Также учитываем расположение сетевых портов на PCI-шине, количество сокетов для последующего маппинга интерфейсов по NUMA-нодам и количество физических ядер на каждом процессоре.
Посмотрим на процесс пошагово
-
Для начала опишем сети, которые будем использовать. Предположим, у нас стандартная двухпортовая on-board сетевая карта и двухсокетная материнская плата.
Имя сети | Назначение | Сеть | Шлюз | VLAN ID | Количество виртуальных адаптеров |
Management | Управляющий интерфейс | 192.168.1.0/24 | 192.168.1.1 | 0 (Native) | 1 |
LiveMigration | Живая миграция | 192.168.2.0/24 | 2 | 2 | |
CSV | CSV-трафик | 192.168.3.0/24 | 3 | 2 |
В результате мы создадим свитч с менеджмент-интерфейсом. MinimumBandwidthMode обязательно сразу задаем как weight, иначе после создания SET мы не сможем изменить этот параметр. Так пропускная способность сети будет указана в относительных числах. Это понадобится для настройки Network QoS Policies (а иначе они не будут работать).
После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и «прибиваем» CSV-трафик и трафик живой миграции к каждому порту:
Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.
Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:
Маппинг необходим, чтобы трафик гарантированно выходил из определенного сетевого порта и не произошла ситуация, когда все сетевые нагрузки уходят в один случайный порт.
До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно.
Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:
Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. В четвертой степени получим 16 – это значение задаем для MaxProcessorNumber.
BaseProcessor для второго адаптера тоже будет равен 16 (опять берем степень двойки). На картинке хорошо виден перехлест для обработки трафика на шестнадцатом ядре. Ситуация не критичная, так как нулевое ядро мы разгрузили и не используем для обработки Live Migration.
Основные требования к средствам резервного копирования ВМ Hyper-V
Это в общих чертах о резервном копировании Hyper-V, но на деле возникает куча нюансов и проблем. Попробую перечислить наиболее распространены проблемы:
- Чем дольше средство резервного копирования забирает снапшот (бэкап) к себе, тем больше изменений накапливается в дельта файлах. При достаточно большом количестве изменений внутри ВМ за время копирования файлов, процесс слияния файлов при удалении снапшота может вызывать высокую нагрузку на диски, Hyper-V хост и саму ВМ. Т.е. желательно максимально быстро забрать снимок. В Hyper-V Server 2016 для ускорения процесса резервного копирования используется технологий Resilient Changed Tracking, которая позволяет средству резевного копирования копировать только блоки данных, измененные с момент последнего бэкапа. При этом не нужно «забирать» ВМ целиком.
- При копировании данных снимка ВМ по LAN сети с хоста Hyper-V на хранилище резервных копий возможно вызвать высокую нагрузку на сеть. Поэтому для трафика резервного копировании желательно использовать отдельный интерфейс сервера, или же копировать данные через SAN сеть.
- Исходя из вышестоящих пунктов при использовании внешних систем хранения для хранения файлов ВМ, вы можете воспользоваться возможностями СХД по интеграции со средствами резервного копирования (аппаратные снапшоты).
- Изначально гостевая ОС не подозревает о том, что создается ее резервная копия. Соответственно при попытке восстановить ВМ из такого бэкапа, ОС пытается продолжить свою работу с момента создания снимка. В некоторых случаях это может вызвать проблемы как с самой ОС, так и с потерей данных в запущенными внутри нее приложениях (особенно в транзакционных, таких как Exchange, SQL, ADDS и т.п.). Для преодоления этой проблемы в Hyper-V 2016 появился новый тип снимков — Production Checkpoints (Microsoft рекомендуется применять обычные снимки — Standard Checkpoint только в тестовых и лабораторных средах, или для бэкапа остановленных виртуальных машин). Производственные снимки работают за счет наличия в гостевой ОС средств интеграции Hyper-V и основываются на технологии Volume Shadow Copy (Windows) или заморозки файловой системы fsfreeze (Linux). Однако состоянии памяти при этом не копируется. Т.е. Hyper-V уведомляет гостевую ОС о создании снимка, приложение с поддержкой VSS корректор завершает текущие транзакции, переходит в консистентное состояние и создается снимок ВМ. При восстановлении из такого снимка гостевая ОС выключена (т.к. состояние памяти не сохранялось), после включения она считает, что просто произошло аварийное отключение по питанию. Приложение (если оно поддерживает VSS) при этом начинает работу с сохранённого согласованного состояния.
- Для хранения бэкапов виртуальных машин нужно достаточно много места. Чем чаще вы делаете снимки и чем дольше должны хранится бэкапы, тем больше места вам нужно в хранилище резервных копий. Как правило вам на помощь может прийти технология дедупликации данных (встроенная в Windows Server) или собственная технология от вендора средства резервного копирования. Если вы используете дифференциальные диски, нужно чтобы средство резервного копирования поддерживало эту технологию. Иначе вы можете хранить одинаковые данные ВМ несколько раз.
Примечание. Есть даже средства восстановления конкретных хранилищ, ящиков и даже отдельных писем из резервной копии ВМ с Exchange.
Далее мы рассмотрим несколько популярных решений по организации резервного копирования ВМ на Hyper-V с точки зрения рассмотренных возможностей.
1.1. Бэкап сегодняшнего дня
Насколько мы знаем, любой Windows умеет делать бэкап. Причем, любые настройки бэкапа Windows через интерфейс сводятся, в конечном счете, к фоновому использованию утилиты wbadmin. А что, собственно, умеет wbadmin? А умеет она делать как бэкап образа с системным разделом, так и бэкап отдельных папок. В данной части статьи нас интересует только бэкап образ (системного раздела). Остальное — это специфичные данные виртуальных машин и бэкапить нужно отдельно. Отсюда вывод: Не храните на системном разделе виртуальных машин (и на обычных компьютерах тоже) никакой ценной информации и баз данных, отдельных приложений. MS SQL Server / MS Exchange / «Сервер приложений 1С» и другое ставим только на не системные разделы или на отдельные диски.
Итак, что же нужно, чтобы бэкап отработал? А нужна всего лишь одна команда:
На самом деле, для этой команды нужны особые права, но о них позже. Сейчас важно понять одну вещь. Данная команда делает не просто бэкап. Она делает инкрементальный бэкап. Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных — снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому что бэкапим мы не весь образ, а только изменившуюся часть со времени последнего бэкапа (а значит и меньше трафика и быстрее создается бэкап).
Те, кто сталкивался с аналогичной ситуацией заметят, что бэкап всегда будет «инкрементальный» (полный). Так как бэкап происходит в нашем случае на сетевой диск. То есть для серверной Windows снимки остаются тоже только последние.
Позже, выявил, что нет никакой разницы в работе wbadmin на серверной и клиентской ОС. Разве, что разница есть в интерфейсе. wbadmin производит инкрементальный бэкап (кроме первого бэкапа), если указан жесткий диск в ключе -backupTarget (команда использует ключ по умолчанию -vssСopy). Или производит полный бэкап, если добавить ключ -vssFull.
Резервное копирование Hyper-V с помощью встроенного Windows Server Backup
Бесплатный способ организации системы резервного копирования ВМ на Hyper-V предполагает использование встроенного Windows Server Backup через графический мастер резервного копирования/восстановления или утилитой wbadmin (входит в состав WSB). Windows Server Backup поддерживает VSS и инкрементальное копирование, эта фича доступна как в полноценной редакции Windows Server 2012 и выше, так и в Hyper-V. Для установки данного компонента нужно воспользоваться консолью Server Manager или командой:
Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools
У WSB есть графическая консоль wbadmin.msc, которая позволяет создавать и управлять резервным копированием Hyper-V, создавать расписание резервного копирования и т.д. Для бэкапа ВМ достаточно запустить простой мастер, в котором нужно выбрать какие ВМ с сервера Hyper-V нужно бэкапить, куда, и указать расписание резервного копирования.
Совет. В предыдущих версиях Hyper-V до 2012 с помощью встроенных средств резервного копирования было нельзя создать резервную копию одной ВМ – бэкапились все виртуальные машины сразу.
Но обычно проще воспользоваться утилитой командной строки wbadmin для бэкапа ВМ Hyper-V. Тем более из графического интерфейса нельзя создать более одного задания резервного копирования ВМ, причем это задание всегда будет перезатирать предыдущие резервные копии.
Чтобы создать резервную копию ВМ с именем Server 1 в локальную папку на диске C: (не самая правильная, идея не так, ли), просто выполните команду:
wbadmin start backup –backupTarget:C: –hyperv:"Server 1"
Например, чтобы создать резервную копию двух ВМ и сохранить их в сетевую папку (допустим это внешнее NAS хранилище), достаточно выполнить команду:
wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:"TestVM01,TestVM 02" -allowDeleteOldBackups -quiet
Вы можете добавить эту команду в планировщик Windows (с помощью того же PowerShell) и тем самым настроить регулярное создание бэкапов ВМ (старые бэкапы при этом удаляются).
Например, при бэкапе ВМ с контроллером домена AD, вы можете по окончании бэкап сбросить транзакционные логи AD, чтобы база ADDS в резервной копии была в консистентном состоянии (аналогично можно сделать бэкап ВМ с Exchange или SQL Server:
wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:MSK-DC1 -vssFull
wbadmin get versions
Совет. Обратите внимание, что при резервном копировании ВМ Hyper-V на хосте с Windows 2012 и выше, ВМ не переводится в режим приостановки, если на ней установлены компоненты интеграции Hyper-V.
С восстановлением ВМ из такого бэкапа все также достаточно просто. Однако вы не можете восстановить из бэкапа один конкретный файл или папку, вам придется вручную смонтировать vhdx файл с резервной копией и также вручную скопировать нужный файл.
При всей своей простоте WSB достаточно надежное решение для резервного копирования ВМ Hyper-V, работает довольно быстро и позволяет управлять расписанием резервного копирования. Но конечно, у Windows Server Backup есть свои недостатки:
- Нет средств мониторинга выполнения бэкапов, проверки консистентности резервных копий ВМ и приложений в них;
- Сложно управлять резервным копированием в средних и крупных инсталляциях Hyper-V (подходит для небольших сред с 1-2 хостами Hyper-V);
- Нельзя автоматически восстановить конкретный файл или состояние приложения (вам придется вручную смонтировать vhdx файл с резервной копией и вручную скопировать нужный файл);
- При большой плотности и размерах виртуальных машин на хосте вам придется с помощью планировщика Windows настраивать порядок создания резервных копий, чтобы не вызвать перегрузки сервера, а также высокой нагрузки на сети LAN/SAN/ iSCSI в рабочие часы (если вы храните бэкапы на другом хранилище).
Как работает резервное копирование виртуальных машин Hyper-V?
Рассмотрим упрощенно схему работы любого современного средства для бэкапа виртуальных машин Hyper-V.
Примечание. Ранее резервное копирование серверов выполнялось за счет установки агента резервного копирования на каждый хост. В эпоху виртуализации точка создания бэкапа сместилась из гостевой ОС на сам Hyper-V хост, на котором запущены ВМ. Агентные сценарии резервного копирования применяются довольно редко, в основном для конкретных приложений, которые не поддерживают VSS.
Средство резервного копирования отдает команду хосту Hyper-V на создание снимка. После получения команды на создание снапшота гипервизор создает новые файлы (дельта-файлы) и ВМ продолжает свою работу, сохраняя изменения в этих файлах них. Теперь задача средства резервного копирования скопировать оригинальные файлы ВМ (изменения в них не пишутся) на носитель резервных копий и после этого удалить снапшот. При удалении снимка Hyper-V производит консолидацию (слияние) исходных и дельта файлов, работа ВМ при этом также не прерывается. В случае потери продуктивной ВМ, вы можете восстановить ее состояние на момент даты создания резервной копии.
Читайте также: