Назад | Перейти на главную страницу

Где DPM использует пространство на защищенном сервере SQL?

Я использую Microsoft System Center Data Protection Manager 2016 для защиты SQL Server 2017 на Windows Server 2016. Я считаю, что всякий раз, когда DPM выполняет резервное копирование (синхронизацию или быстрое полное заполнение), он будет временно использовать некоторое пространство на узле SQL Server, прежде чем данные будут передается на сервер DPM.

Я нашел некоторую поддержку этого убеждения, особенно для резервных копий журналов транзакций, в https://blogs.technet.microsoft.com/dpm/2013/08/21/optimizations-in-protecting-sql-databases-with-high-churn-by-dpm/ что говорит (частично)

Файлы временного журнала транзакций хранятся в папке с именем «DPM_SQL_POTECT \» + «MachineName» + «Имя экземпляра SQL Server \» + «Имя базы данных» + «_log.ldf \ Backup \». Эта папка создается в том же месте, что и местоположение файла определения журнала.

(обратите внимание, что в другом месте сообщения становится ясно, что имя каталога фактически начинается DPM_SQL_PROTECT, в процитированной части просто опечатка).


Однако мне не удалось найти аналогичной информации о временном использовании пространства для быстрого полного резервного копирования (которое было бы полным резервным копированием базы данных SQL Server). При просмотре файлов DPMRA.errlog на защищенном сервере SQL можно предположить, что используется локальное пространство теневых копий VSS:

CMultiVolumeUsnIterator: AddIncludeFiles (путь к файлу: e: \ Program Files \ Microsoft SQL Server \ MSSQL14.SQLNGR1 \ MSSQL \ Data \, filespec: kslds.mdf, путь к моментальному снимку: \? \ GLOBALROOT \ Device \ HarddiskVolumeShadowCopy9 \ Program Files \ Microsoft SQL Server \ MSSQL Server \ Microsoft SQL Server .SQLNGR1 \ MSSQL \ Data)

но я не уверен, что правильно это интерпретирую. Кроме того, на этом защищенном сервере, несмотря на то, что было выполнено много экспресс-полных резервных копий, vssadmin list shadowstorage отчеты

Товаров, удовлетворяющих запросу, не найдено.

что, кажется, противоречит идее об использовании пространства VSS.


Наконец, в собственных журналах SQL Server есть записи, соответствующие экспресс-полному резервному копированию, которые идентифицируют устройство дампа как

информация об устройстве: (FILE = 1, TYPE = VIRTUAL_DEVICE: {'{990A7582-1356-4B6B-8D70-8F3235748794} 1'})

в котором GUID, кажется, меняется каждый раз, но я не смог найти никакого объяснения того, какое реальное хранилище находится за виртуальным устройством.


Кто-нибудь знает, как определить (и, возможно, контролировать) местоположение и объем пространства, используемого на защищенном сервере для этих резервных копий?

Спасибо!

Мартин

По данным службы поддержки Microsoft, с небольшими исправлениями опечаток и т. Д .:

В случае быстрой полной резервной копии DPM создаст теневую копию тома, на котором размещены файлы базы данных SQL. Поскольку записи выполняются в файлы журнала SQL и базы данных, копирование при записи копирует данные в файл моментального снимка, расположенный в папке информации системного тома. Размер моментального снимка будет зависеть от продолжительности резервного копирования и объема передачи данных (изменений в файлах) во время выполнения резервного копирования.

Пространство используется на томах, на которых размещены файлы базы данных и журналов. Для Express Full вы можете перенаправить расположение моментальных снимков VSS с помощью VSSADMIN.EXE, удалив текущее пространство теневого хранилища и добавив его на другой том. Например, чтобы перейти от E: к S: volume:

vssadmin Delete ShadowStorage /For=E: /On=E:
vssadmin Add ShadowStorage /For=E: /On=S: /MaxSize=UNBOUNDED


Также для поддержки MS:

Если все базы данных SQL находятся в одной группе защиты, они будут выполнять последовательное резервное копирование, и каждая резервная копия будет создавать новую теневую копию, по одной за раз. Если базы данных SQL находятся в отдельных PG, но запланированы для одновременного запуска, то будет активным несколько теневых копий.


Наконец, служба поддержки MS подтвердила, что описание хранения временных копий файла журнала транзакций (как описано в вопросе) по-прежнему верно для SQL Server 2017, DPM 2016 и Windows Server 2016.