Я не системный специалист или администратор баз данных, и когда я рассматривал заявку на проект, я начал задаваться вопросом, как резервное копирование на магнитной ленте (LTO-5 3000) влияет на живые производственные приложения, такие как базы данных Sql Server в Windows Server (2012) .
По моему опыту, файлы базы данных полностью заблокированы и не могут быть скопированы. Моя первая мысль заключалась в том, что можно использовать репликацию SQL Server на вторичный (виртуальный) сервер. Затем сервер можно настроить на выполнение дампа / резервного копирования по расписанию. Это «предписанный» подход? Если нет, то каков общий подход к резервному копированию баз данных Sql Server?
Говоря о блокировке файлов базы данных, я думаю, что вы собираетесь делать резервные копии баз данных совершенно неверным способом, если пытаетесь скопировать сами файлы базы данных и жалуетесь, что они заблокированы. Они не только «заблокированы», как вы заметили, простое копирование файлов было бы отличным способом получить резервную копию базы данных, которую невозможно надежно восстановить.
Все известные мне продукты серверов баз данных будут иметь какую-то внутреннюю систему резервного копирования, которую вы должны использовать для резервного копирования данных. Это будет либо процедура полного резервного копирования, которая позволяет выгружать данные в файл или ленту напрямую, либо это будет API, к которому могут подключаться сторонние резервные копии, чтобы запустить резервное копирование, которое полностью поддерживается продуктом. MSSQL может использовать оба этих метода.
Я бы посоветовал использовать внутреннюю резервную копию SQL для резервного копирования на «файловое устройство» на жестком диске, а затем вы можете создавать резервные копии этих файлов на магнитной ленте на досуге.
редактировать Чтобы ответить на ваш комментарий,
1) Влияние с помощью поддерживаемый метод резервного копирования должен быть минимальным, хотя, очевидно, должно быть какое-то влияние. Я бы не хотел просто сказать: «О, это будет Икс% медленнее »или что-то в этом роде: это вещь« протестируй и увидишь ». Я скажу, что это не должно приводить к недоступности базы данных.
2) Существует два «стандарта» - резервное копирование на диск с использованием внутренней процедуры резервного копирования с последующим резервным копированием результатов на ленту / другое хранилище, расположенное поблизости от сети, и / или резервное копирование непосредственно на ленту с помощью агента резервного копирования, поддерживающего базу данных. Я бы не сказал, что один метод лучше другого (я видел серьезные базы данных, защищенные обоими методами), но я предпочитаю использовать либо метод SQL-> Disk-> Tape, либо или SQL-> Диск-> Лента и SQL-> агент резервного копирования-> Лента.
Вот отличная ссылка для новичков, чтобы узнать о резервных копиях MSSQL:
http://msdn.microsoft.com/en-us/library/ms187510.aspx
MSSQL использует службу теневого копирования томов Windows (VSS) для получения доступа к файлам данных, аналогичных моментальным снимкам; НИКОГДА не пытайтесь копировать файлы данных вручную - это просто не сработает.
Ответ на ваш вопрос: «Это зависит», но я постараюсь дать достаточно информации, чтобы вы могли принять решение.
При резервном копировании на ленту вы должны учитывать, что ленты намного медленнее, чем диски, это означает, что BACKUP / VERIFY / RESTORE будет медленным, а при большом количестве данных (терабайт) это может занять много часов. Вы можете использовать собственный метод sql server для достижения этого или использовать какое-либо стороннее программное обеспечение, такое как Idera / Redgate / CommVault / и т. Д.
Другой вариант - сделать резервную копию на локальный диск, например: дешевый SAN или другой массив Raid. Ключ здесь РАЗНЫЙ! Что вы делаете, так это используете собственный метод sql-сервера для резервного копирования на выделенный раздел резервного копирования / lun / raid set / диск, чтобы у вас было достаточно места для хранения, чтобы вы могли вращать файлы резервных копий. Ключ в том, чтобы иметь достаточно свободного места на N + 1 дней, которое вы хотите хранить локально. Затем вы настраиваете резервную копию на ленту для резервного копирования этих файлов на ленту.
Основным преимуществом здесь является то, что задание резервного копирования выполняется быстрее, а это означает, что оно выполняется меньше времени на вашем SQL Server, а поскольку резервные копии находятся в другом хранилище, чем ваши файлы данных SQL и файлы журналов (MDF, NDF, LDF), влияние на SQL Server практически ничего нет и это не проблема.
Еще одним важным преимуществом является то, что у вас есть последняя резервная копия, готовая к восстановлению, это восстановление будет намного быстрее, чем восстановление с ленты, что минимизирует время простоя в таком случае.
Я бы настроил это вторым методом.
Если вы используете журналы транзакций, убедитесь, что ваши модели восстановления установлены на ПОЛНЫЙ.
Если у вас есть SQL Enterprise, вы даже можете сжать резервные копии, чтобы они занимали меньше места. Если нет, есть сторонние инструменты, которые могут сжать его для вас от таких поставщиков, как Idera или Red-Gate. Также есть отличный проект с открытым исходным кодом, который я использую под названием MSSQLCOMPRESSED
Надеюсь, это ответит на ваш вопрос.