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