Резервне копіювання Windows Server не призначене як інструмент резервного копіювання для SQL Server.
... Однак дизайн робить його особливо підходящим для менших організацій або осіб, які не є ІТ-професіоналами ...
Цитата з розділу " Посібник із резервного копіювання Windows Server" для розділу " Windows Server 2008 ": "Хто повинен використовувати резервну копію Windows Server?"
У розділі, який ви цитували, в основному йдеться про те, що, коли запускається резервна копія Windows Server, це запустить функцію VSS у Windows. SQL Server буде в курсі, що відбувається копіювання тонів у тім і за допомогою служби SQL Server Writer забезпечить можливість копіювання файлів бази даних (* .mdf, * .ndf, * .ldf).
Мета служби SQL Server Writer визначається наступним чином:
Під час роботи Database Engine блокується та має ексклюзивний доступ до файлів даних. Якщо служба SQL Writer не запущена, програми резервного копіювання, що працюють у Windows, не мають доступу до файлів даних, а резервні копії повинні виконуватися за допомогою резервного копіювання на SQL Server.
Використовуйте службу SQL Writer, щоб дозволити програмам резервного копіювання Windows копіювати файли даних SQL Server під час роботи SQL Server.
Цитата з розділу служби обслуговування SQL Writer : "Призначення"
Отже, це в основному все, що відбувається з резервною копією Windows Server.
Резервні копії, створені за допомогою резервного копіювання Windows Server під час роботи SQL Server, повинні бути узгодженими, але транзакції, ще не записані на диск, не містяться в тіньовій копії. Знімок із бази даних був зроблений під час роботи в режимі ONLINE.
Однак у статті MSDN Snapshot Backup створюється :
Можливі резервні копії лише таких типів:
- Повні резервні копії
- Часткове резервне копіювання
- Резервні копії файлів
- Диференціальні резервні копії бази даних. Вони підтримуються лише тоді, коли постачальник використовує інтерфейс VSS.
і додатково:
За винятком випадків, зазначених раніше в цій темі, резервні копії знімків функціонально еквівалентні відповідним звичайним резервним копіям. Ви можете використовувати резервні копії знімків у послідовностях відновлення з неповними знімками повних резервних копій, диференціальних резервних копій та резервних копій журналу. Як і інші резервні копії, резервні копії знімків відслідковуються в базі даних msdb, де резервні копії знімків ідентифікуються backupset.is_snapshot = 1. Для отримання додаткової інформації про msdb див.
SQL Server не підтримує відновлення в Інтернеті з резервного копіювання знімків. Відновлення резервної копії знімка автоматично переносить базу даних в автономний режим. Часткове відновлення може включати резервні копії знімків, але всі послідовності відновлення відновлені в режимі офлайн. Для отримання додаткової інформації про відновлення з частин, див. Виконання відновлювальних деталей.
Щоб відповісти на ваші запитання:
- Мені просто потрібно створити резервну копію .mdf? .Mdf та .ldf?
- Інтернет чи просто офлайн?
- Яка офіційна процедура відновлення резервних копій баз даних SQL Server?
- Чи є щось особливе, що слід враховувати, роблячи додаткові / диференційні резервні копії?
- Де все це документально зафіксовано?
Відповіді:
- Так, ви можете зробити резервну копію (VSS) для Windows Server копії файлів .mdf та .ldf. Резервне копіювання повинно бути послідовним, але база даних буде відновлена після відновлення.
- Якщо SQL Server зупинений / база даних від'єднана / база даних ВИМКНЕНО, копія VSS файлів .mdf та .ldf відповідає 100%.
- Я не знаю, як відновити базу даних (до моменту часу), яка ведеться із резервною копією Windows Server, тому що база даних відновлюється в офлайн-стані. База даних у стані OFFLINE більше не може бути відновлена / відновлена, і приведення результатів ONLINE бази даних в базу даних вважається повністю відновленою. Я рекомендую окремі резервні копії SQL Server FULL, DIFF та TLOG, щоб забезпечити можливість відновлення бази даних до моменту часу.
- Журнали транзакцій не є частиною знімків, створених за допомогою резервного копіювання Windows Server, і їх слід виконувати додатково. Диференційні знімки підтримуються сторонніми постачальниками як частина резервної копії, але схоже, що резервне копіювання Windows Server не може виконати диференціальне резервне копіювання. У цьому випадку вам також доведеться виконати додаткові резервні копії. (див. 3.)
- Різні посилання
Пояснюється в реальному житті
У нашому середовищі у нас схожа ситуація, коли VMware проводить знімок, а DBA проводить скидання SQL Server із Commvault. Історія створення резервних копій виглядає приблизно так:
DBNAME TYPE BACKUPSET_NAME IS_SNAPSHOT BACKUP_START_DATE
------- ---- ------------------------- ----------- -----------------------
DB_NAME Full NULL 1 2016-12-10 18:23:59.000
DB_NAME Full CommVault Galaxy Backup 0 2016-12-10 20:07:41.000
DB_NAME Log CommVault Galaxy Backup 0 2016-12-11 06:00:40.000
DB_NAME Full NULL 1 2016-12-11 18:24:00.000
DB_NAME Diff CommVault Galaxy Backup 0 2016-12-11 20:03:38.000
DB_NAME Log CommVault Galaxy Backup 0 2016-12-12 06:02:29.000
DB_NAME Log CommVault Galaxy Backup 0 2016-12-12 07:02:17.000
Знімок VMware створює запис в таблицях бази даних історії MSDB з IS_SNAPSHOT = 1і FULLдля кожного знімка VMware , які проводяться (щодня). Нативні (добре Commvault з використанням нативного) резервного копіювання SQL Server проводяться з використанням резервних копій FULL, DIFF та TLOG. Ці резервні копії не позначені як IS_SNAPSHOT і існують як додаткові ПОВНІ (раз на тиждень), DIFF (через день) та LOG (щодня) у таблицях резервного копіювання в базі даних msdb.
За допомогою цього налаштування ми можемо виконати відновлення дати та часу знімка, а потім піднести базу даних ONLINE, або ми зможемо виконати індивідуальне відновлення до будь-якого моменту часу, використовуючи "нативні" резервні копії SQL Server.