Существует множество программного обеспечения, которое создает резервную копию SQL Server непосредственно из базы данных, а не выполняет резервное копирование файла, который был извлечен из SQL Server. Я всегда боялся его использовать с точки зрения его влияния на производственную систему. У кого-нибудь есть опыт с этим? Это надежно? Имеет ли значение, какой продукт вы используете, или он взаимодействует с известными API-интерфейсами SQL Server, поэтому на самом деле это не имеет значения?
Собственные резервные копии так же надежны, как и сторонние инструменты. Сторонние инструменты фактически используют собственное резервное копирование для резервного копирования базы данных. Они просто настраивают виртуальный ленточный накопитель и создают резервную копию на этом устройстве. Это устройство на самом деле есть DLL, которые делают дополнительное сжатие и т. Д. В резервной копии.
Резервное копирование файлов базы данных через сетевое резервное копирование без остановки базы данных SQL Server НЕ поддерживается и не должно использоваться.
У меня есть опыт (помимо встроенных функций резервного копирования SQL Server) с Redgate SQL Backup и Quest LiteSpeed для SQL Server, которые надежны и работают быстрее, чем собственное резервное копирование SQL. Оба они устанавливают расширенные хранимые процедуры в ваш экземпляр SQL. По моему опыту, гораздо надежнее использовать один из этих продуктов или даже встроенную функцию резервного копирования SQL, чем выполнять резервное копирование с уровня файловой системы. У вас также есть гораздо больше возможностей, доступных для использования собственного резервного копирования SQL или стороннего пакета резервного копирования.
Резервные копии SQL Server относятся к корпоративному уровню. Вы можете создать пакетный сценарий для резервного копирования базы данных, а затем запустить его в планировщике.
Мы не покупали ничего, кроме SQL Server 2008 (то же самое относится и к 2005 году), и у нас есть следующие возможности аварийного восстановления: * ежедневное резервное копирование каждой производственной базы данных в файле с использованием пакетного сценария * репликация производственных баз данных на сервер резервного копирования - сбой Производственная система требует только изменения конфигурации в веб-приложении.
В SQL Server есть система предупреждений, которая сообщит вам, если что-то пойдет не так. Влияние на производство было минимальным, и наш DRA достаточно силен, учитывая, что мы не платили ничего дополнительно. У нас есть данные о 3+ физических местоположениях, и в худшем случае мы потеряем данные только за день.
Надежность любой резервной копии зависит от соответствующего восстановления..
Я получил живые таблицы SQL2005 обратно с помощью агента Backup Exec, совершенно незаметно и чисто. Для выполнения своей работы он использует теневое копирование тома, а не SQL API, но я ожидаю, что средство записи SQL VSS в любом случае использует API внутри (на самом деле VSS - это лишь общий интерфейс для резервного копирования и восстановления в конце дня).
Если вам действительно нужно резервное копирование в реальном времени, вы можете попробовать репликацию базы данных