Як створити резервну копію баз даних SQL в мережевому ресурсі

Регулярно створювати резервні копії баз даних SQL. Ми вже розглянули способи легко створити резервну копію всіх баз даних на сервері SQL на локальному жорсткому диску, але це не захищає від збоїв у роботі диска та / або системи. Як додатковий рівень захисту від цього типу катастрофи, ви можете скопіювати або безпосередньо створити резервні копії на спільному ресурсі мережі.

Резервне копіювання локально, а потім скопіювати в мережевий ресурс

Кращим і найбільш прямим способом досягнення цього завдання є створення локальної резервної копії бази даних, а потім копіювання відповідного файлу резервної копії до спільного ресурсу мережі. Це можна зробити, створивши пакетний сценарій, який виглядає так:

SET LocalFolder = C: Файли програмиMicrosoft SQL ServerMSSQL.1MSSQLBackup
SqlCmd -E -Q “Резервна база даних MyDB To Disk ="% LocalFolder% MyDB.bak ""
XCopy “% LocalFolder% MyDB.bak” “\ t
DEL “% LocalFolder% MyDB.bak”

Цей сценарій виконує наступне (рядок за рядком):

1. Встановлює змінну в локальний каталог резервного копіювання SQL.
2. Створює резервну копію SQL MyDB (за допомогою перевірки автентичності Windows) у локальному каталозі резервного копіювання SQL.
3. Копіює локальний файл резервної копії до спільного ресурсу мережі.
4. Видаляє локальний файл резервної копії.

Знову ж таки, це кращий метод, тому що він працює з коробки, і ймовірність збою резервного копіювання є мінімальною, оскільки резервне копіювання створюється на локальному диску. Однак, якщо у вас недостатньо місця на диску для зберігання локальних копій резервних копій, ця дія не вдасться. У цьому випадку вам потрібно буде додати додатковий дисковий простір або резервну копію безпосередньо до спільного ресурсу мережі.

Резервне копіювання безпосередньо в мережевий ресурс

Зазвичай, коли ви намагаєтеся створити резервну копію безпосередньо до спільного ресурсу мережі, використовуючи таку команду, як:

SqlCmd -E -Q «Резервна база даних MyDB To Disk =" \ t

Найчастіше ви отримаєте помилку за:

Повідомлення 3201, рівень 16, стан 1, сервер JF, лінія 1
Не вдається відкрити пристрій резервного копіювання '\ t Помилка операційної системи 5 (Доступ заборонено.).
Звіт 3013, рівень 16, стан 1, сервер JF, лінія 1
BACKUP DATABASE закінчується ненормально.

Ця помилка виникає, незважаючи на те, що ви виконували команду резервного копіювання SQL, використовуючи перевірку автентичності Windows (перемикач -E) і обліковий запис Windows, як можливість доступу та копіювання файлів до спільного ресурсу за допомогою Провідника Windows.

Причиною невдалої дії є те, що команда SQL виконується в межах облікового запису, з яким працює служба SQL Server. Коли ви переглядаєте список служб на вашому комп'ютері, швидше за все, ви побачите службу SQL Server, що працює як (стовпець входу в систему) або локальну систему, або службу мережі, які є системними обліковими записами, які не мають доступу до мережі.

У нашій системі резервне копіювання до команди спільного доступу до мережі не відбувається, тому що служба SQL Server працює як локальна система, яка, знову ж таки, не може отримати жодних мережевих ресурсів.

Для того, щоб дозволити SQL резервного копіювання безпосередньо на мережевий ресурс, ми повинні запустити службу SQL Server як локальний обліковий запис, який має доступ до мережевих ресурсів..

Відредагуйте властивості служби SQL Server і на вкладці "Увійти" налаштуйте службу на виконання як альтернативний обліковий запис, який має права доступу до мережі.

Після натискання кнопки "ОК" з'явиться нагадування про те, що налаштування не наберуть сили до перезапуску служби.

Перезапустіть службу.

Список послуг повинен тепер показувати, що служба SQL Server працює як налаштований обліковий запис.

Тепер, коли ви виконуєте команду для резервного копіювання безпосередньо до спільного ресурсу мережі:

SqlCmd -E -Q «Резервна база даних MyDB To Disk =" \ t

Ви повинні побачити повідомлення про успіх:

Оброблено 152 сторінки для бази даних 'MyDB', файл 'MyDB' у файлі 1.
Оброблено 2 сторінки для бази даних 'MyDB', файл 'MyDB_log' у файлі 1.
BACKUP DATABASE успішно обробили 154 сторінки за 0,503 секунди (2,494 МБ / сек).

З резервним файлом зараз у каталозі спільного доступу до мережі:

Мережеві міркування

Важливо відзначити, що команда резервного копіювання очікує можливість безпосереднього підключення до спільного ресурсу мережі без запиту на вказівки. Обліковий запис, на якому налаштовано службу SQL Server, який має працювати, повинен мати надійне з'єднання з мережевим ресурсом, де відповідні облікові дані дозволяють доступ, інакше може статися така помилка:

Повідомлення 3201, рівень 16, стан 1, сервер JF, лінія 1
Не вдається відкрити пристрій резервного копіювання '\ t Помилка операційної системи 1326 (помилка входу в систему: невідоме ім'я користувача або поганий пароль)..
Звіт 3013, рівень 16, стан 1, сервер JF, лінія 1
BACKUP DATABASE закінчується ненормально.

Ця помилка вказує, що ім'я користувача та пароль облікового запису не були прийняті спільним доступом до мережі, і команда не вдалася.

Інша проблема, про яку слід пам'ятати, це резервне копіювання, яке виконується безпосередньо на мережевому ресурсі, тому будь-які збої в підключенні до мережі можуть призвести до помилки резервного копіювання. Тому потрібно створювати резервні копії лише в мережевих місцях, які є стабільними (тобто, можливо, не є VPN).

Наслідки безпеки

Як згадувалося раніше, використання способу локального резервного копіювання, а потім копіювання до спільного ресурсу мережі, є кращим, оскільки дозволяє вам запускати службу SQL як обліковий запис лише з доступом до локальної системи.

Запускаючи службу як альтернативний рахунок, ви відкриваєте двері для потенційних проблем безпеки. Наприклад, шкідливий скрипт SQL може виконуватись під альтернативним обліковим записом і атакувати мережеві ресурси. Крім того, будь-які зміни відповідного облікового запису (зміни пароля / закінчення терміну дії чи видалення / вимкнення облікового запису) призведуть до невдалої запуску служби SQL Server.

Важливо мати на увазі ці моменти, якщо ви запускаєте примірник SQL Server за допомогою альтернативного облікового запису. Хоча це не показують стопери, якщо вжито належних заходів безпеки, слід розглянути можливість додавання додаткового місця на жорсткому диску, а потім реалізувати локальне резервне копіювання та копіювання, щоб можна було запустити службу SQL за допомогою локального облікового запису..