Я знаю, что Microsoft SQL Server нигде не подтверждает, что он безопасен, верен, действителен или предназначен для резервного копирования данных (.mdf) и журнал (.ldf) файлы (* во время работы SQL Server). то есть вы не знаете, в каком состоянии находятся эти файлы - это не ваши файлы.
Некоторое программное обеспечение для резервного копирования утверждает, что может создавать резервные копии данных и файлов журналов SQL Server, пока они используются.
Не обращайте внимания на тот факт, что если это (происходит) срабатывает - это предполагаемое поведение?
Обычно программа, поддерживающая SQL, использует модуль записи VSS для создания моментального снимка базы данных на определенный момент времени. Если вы начнете резервное копирование в 11 утра, а данные будут введены в 11:01, они не будут включены в резервную копию.
Да, это действительно ЕСЛИ (!) Программа полностью интегрируется в резервную точку доступа, которую предлагает Windows. В основном они УКАЗЫВАЮТ, что SQL Server переводит файлы в согласованное состояние, а затем создается моментальный снимок файла. Это термин VSS (Volume Shadow Copy), и для этого есть API. SQL Server поддерживает это.
Использование программы резервного копирования с поддержкой SQL (например, Symantec BE) вполне приемлемо. Symantec BE не создает резервные копии файлов mdf и ldf напрямую, и вы не найдете файлов mdf или ldf ни в одном из ваших наборов резервных копий SQL-сервера.
Я бы не рекомендовал делать резервную копию реальных файлов, используемых SQL-сервером. Мы видели проблемы с утилитой резервного копирования, блокирующей фактические файлы данных, что приводило к зависанию и приводило к регистрации следующих ошибок в журнале ошибок SQL:
Date Time spid51 Database master: IO is frozen for snapshot
Date Time spid51 Database master: IO is thawed
См. Следующее:
http://support.microsoft.com/kb/903643
http://sqlbie.wordpress.com/2010/08/31/io-is-thawedfrozen-when-using-3rd-party-backup-agents/
Точно так же и прошлые работодатели (в том числе и мой нынешний), как правило, используют что-то подобное через репликацию SAN, где файлы данных реплицируются в резервную копию SAN на объекте аварийного восстановления.
Фактические тесты восстановления показали, что, хотя это была посекторная копия файлов данных (ldf, mdf и ndf), мы иногда сталкивались с повреждениями из-за неполной записи сектора, которая не была завершена в DR SAN.