Azure резервное копирование приложения, создание частичных резервных копий

Question

Azure Служба приложения настроена для резервного копирования и создает резервные копии с частичным статусом «Частично успешно». Журналы ошибок показывают, что некоторые файлы пропускаются из процесса резервного копирования из-за блокировки файлов.

Retrieve site meta-data. 

Backing up the databases. 

Backing up site content and uploading to the blob... 

File skipped - \data\jobs\continuous\IndexWorker\singleton.job.lock: Sharing violation to C:\Resources\directory\<sometext>.ControllerRole.BackupRestore\<someguid>\package\fs\data\jobs\continuous\IndexWorker\singleton.job.lock 

File skipped - \LogFiles\ApplicationInsights\status\status_<somesuffix>.json: Sharing violation to C:\Resources\directory\<someguid>.ControllerRole.BackupRestore\<someguid>\package\fs\LogFiles\ApplicationInsights\status\status_<somesuffix>.json 

Uploading metadata to the blob. 

Backup completed!

В документации Azure есть возможность исключить файлы в azure процессе резервного копирования https://docs.microsoft.com/en-us/azure/app-service/manage-backup#exclude -files-from-your-backup , но мне интересно, есть ли еще обязательные файлы, которые не следует исключать.

Также полезны ли эти частичные резервные копии и можем ли мы их использовать? Хотя шаги указаны на странице: https://docs.microsoft.com/en-us/azure/app-service/web-sites-restore, чтобы восстановить эти частичные резервные копии вручную. Есть ли какие-либо восстановленные частичные резервные копии.

Как правильно обрабатывать сценарий частичного резервного копирования, исключая файлы-виновники из процесса резервного копирования или восстанавливая вручную эти частичные резервные копии, или есть какой-либо другой способ справиться с этим?

Answer 1

ОБНОВЛЕНИЕ

Вам необходимо создать файл _backup.filter самостоятельно. Вот официальный документ и снимок экрана. И понимание резервной копии файла журнала заключается в следующем, я надеюсь получить одобрение.

Пока файл журнала не удаляется вручную, безопасность данных файла журнала может быть гарантирована. Часть резервной копии программы предназначена для программы, чтобы гарантировать, что указанная версия программы может быть восстановлена, но данные по-прежнему нуждаются в самой последней версии, верно? Поэтому я думаю, что если данные журнала, которые вам нужны, очень важны, я предлагаю, чтобы при регистрации этой части данных вы сохраняли ее в базе данных. При нормальных обстоятельствах файл журнала не должен следовать программе для резервного копирования, потому что после резервного копирования будет операция восстановления, а данные между различиями между двумя версиями будут потеряны после восстановления.

PRIVIOUS

Функция частичного резервного копирования - создать файл с именем _back.filter и указать, какие каталоги или файлы не участвуют в резервном копировании. Как правило, файлы ресурсов stati c, которые никогда не изменяются, не нуждаются в резервном копировании, а другие - в резервном.

Это похоже на развертывание веб-сайта в IIS. Предположим, есть папка Asset, содержимое которой никогда не удаляется. Мы можем установить эту папку без резервного копирования. Остальные папки, такие как bin, Scripts, Contents, et c. может быть из-за программы Есть изменения в обновлении. Эта часть файла должна быть зарезервирована. При восстановлении файлов будет восстановлено только содержимое резервной копии.