Предисловие
Современные системы резервного копирования восстановления имеют большие возможности по резервному копированию, в частности снимать копии и восстанавливать такие вещи как базы данных, Active Directory, Exchange на уровне бэкапов виртуальных машин. В терминологии Symantec Backup Exec данная возможность именуется Granular Recovery Technology (GRT).
Всё бы было здорово и замечательно, но перед использованием резервного копирования сложных систем на уровне GRT настоятельно рекомендую ознакомиться с принципами работы данной технологии и подумать следует ли её использовать в Вашем конкретном случае.
Теперь расскажу одну интересную историю из реальной жизни
У нашего заказчика возникла проблема с восстановлением баз данных MS SQL (в общем случае не принципиально) в родное местоположение с ошибкой V-79-57344-4629 The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job.
|
Errors |
|
Click an error below to locate it in the job log
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 190.0 GB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 380.0 GB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 570.0 GB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 760.0 GB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 950.0 GB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 1.1 TB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 1.3 TB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 1.5 TB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 1.7 TB space is required to stage this job.
V-79-57344-4629 - The staging location C:\TEMP on the Backup Exec server does not have enough disk space to stage the restore job. The server has 10.1 GB space available, but 1.9 TB space is required to stage this job.
|
При этом, размер базы данных не превышал 2ГБ.
Выбирая разные резервные копии требуемый размер изменялся от 290 ГБ до 1,9ТБ
Придется поверить, что для восстановления действительно требуется указанное пространство в директории для восстановления GRT.
Причина
Причина заключалась в том, что для восстановления базы данных из GRT требовалось выгрузить во временную директорию все зависимые Backup Set's (образы резервных копии) виртуальных машин, а так же все зависимые Backup Set произведенные агентом.
Объяснение этому простое: инкрементальные резервные копии необходимые для восстановления содержались как в Backup Set'ах виртуальных машин, так и в Backup Set'ах произведенных агентом,
ИНЫМИ СЛОВАМИ
каждая операции резервной копии MS SQL выполняет резервное копирование Transaction Log'ов, которые существуют от резервной копии до резервной копии и, соответственно, для восстановления требуются все произведенные Backup Set'ы содержащие Transaction Log'и баз данных с момента последнего полного бэкапа до необходимого состояния.
Решение
Решением является отключение GRT в резервном копировании виртуальных машин, или (что является правильным решением с точки зрения проектирования и планирования резервного копирования) максимальной фрагментации на различные задачи резервного копирования целевых систем, т.е. В нашем случае достаточно исключить нашу систему с MS SQL из бооольшой задачи резервного копирования.
P.S.
Если Вы еще не осознали причинно-следственную связь причины и проблемы, и задаетесь вопросом "А как же всё таки нам восстановить необходимые резервные копии?", резюмирую, - предоставьте на систему с Backup Exec требуемое пространство и переместите каталог для временных файлов восстановления GRT на раздел с необходимым пространством.
