Програми для резервного копіювання sql server. Налаштування регулярного резервного копіювання БД MS SQL Server. Відновлення бази даних з резервної копії

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

1. Ручний метод копіювання структури таблиці

У Micrisoft SQL Management Studio вибрати базу, вибрати таблицю, натиснути правою кнопкою миші і вибрати пункти "Script Table as" -\u003e "CREATE TO" -\u003e "New Query Editor Window". У вікні запиту відкриється код для створення таблиці. У ньому потрібно вказати ім'я бази, в якій потрібно зробити копію таблиці, і нове ім'я, якщо база не змінюється. Як створити код для створення структури, що є таблиці, показано на малюнку нижче.

За допомогою цього способу будуть створені індекси таблиці, але не скопійовано тригери. Їх потрібно копіювати аналогічним способом.

Для копіювання даних в уже створену таблицю потрібно використовувати такий SQL запит:

INSERT into ..tmp_tbl_Deps SELECT * FROM ..tbl_Deps

2. Копіювання SQL таблиці запитом в один рядок

Зробити копію структури таблицю і даних всередині однієї бази:

SELECT * into tmp_tbl_Dep FROM tbl_Deps

Скопіювати структури таблицю і її дані з однієї бази в іншу:

SELECT * into ..tmp_tbl_Deps FROM ..tbl_Deps

Мінус у такого рішення - чи не копіюються індекси.

Розглянемо, як організувати дві найбільш часто зустрічаються завдання адміністрування SQL Server'а:

Автоматичне резервне копіювання баз даних;
Видалення старих резервні копії.

Планування резервних копій бази даних

Відкрийте SQL Management Studio та підключіться до необхідної базі даних. Переконайтеся, що SQL Server Agent працює;
Розгорніть вузол Management - Maintenance (для цього у Вас повинна бути роль «SYSADMIN») - клацніть правою кнопкою і виберіть «New Maintenance Plan»;
Введіть ім'я нового плану обслуговування;
Клацніть по іконці календаря справа в єдиному рядку. У вікні, налаштуйте час виконання завдання. Виберіть такий час, коли база даних менше завантажена;
З розділу Toolbox перетягніть завдання Backup Database Task в основну область;
Двічі клацніть по Backup Database Task - відкриється вікно налаштувань завдання резервного копіювання - задайте потрібні настройки;
Клацніть ОК - тепер резервні копії будуть створюватися відповідно до запланованого часом;

Видалення старих резервних копій

Так як файли резервних копій будуть створюватися часто, то незабаром вільного місця на жорсткому диску у Вас зменшиться. Тому Вам потрібно буде видаляти застарілі файли резервних копій. Продовжимо конфігурувати план обслуговування:

З панелі Toolbox перетягніть в основну область задачу Maintenance Cleanup Task;
Двічі клацніть по Maintenance Cleanup Task, щоб відкрити вікно властивостей. У ньому Ви повинні визначити розташування резервних копій, їх розширення і визначити вік файлів що підлягають видаленню. Доброю практикою є зберігання резервних копій до одного місяця;
Тисніть ОК і зберігаєте план обслуговування;
Далі можете або дочекатися наступного часу виконання плану обслуговування, або виконати його вручну (правою кнопкою миші по плану обслуговування в Object Explorer).

Адміністратори БД діляться на тих, хто робить бекапи, і тих, хто буде робити бекапи.

Вступ

У цій статті описано звичайнісіньке резервне копіювання ІБ 1С за допомогою інструментів MS SQL Server 2008 R2, пояснено чому слід робити саме так, а не інакше, і розвіяно кілька міфів. У статті досить багато посилань на документацію MS SQL, ця стаття скоріше огляд механізмів резервного копіювання, ніж всеосяжне керівництво. Але для тих, хто стикається з цим завданням вперше, дані прості і покрокові інструкції, Які застосовні до простих ситуацій. Стаття призначена не для гуру адміністрування, гуру і так все це знають, але передбачається, що читач здатний сам встановити MS SQL Server і змусити це чудо ворожої техніки створити в своїх надрах базу даних, яку в свою чергу він же здатний змусити зберігати дані 1С.

Я вважаю команду TSQL BACKUP DATABASE (і її брата BACKUP LOG) по суті єдиним засобом резервного копіювання баз 1С, що використовують MS SQL Server в якості СУБД. Чому? Давайте розглянемо, які у нас способи взагалі є:

як	добре	погано	Разом
Вивантаження в dt	Дуже компактний формат.	Довго формується, вимагає монопольного доступу, не зберігає частину малозначних даних (таких як настройки користувачів в ранніх версіях), довго розгортається.	Це не стільки спосіб резервного копіювання, скільки спосіб перенесення даних з одного середовища в іншу. Ідеальний для вузьких каналів.
Копіювання файлів mdf і ldf	Дуже зрозумілий спосіб для початківців адміністраторів.	Вимагає звільнення файлів бази даних від блокування, а це можливо, якщо база відключена (команда take offline контекстного меню), від'єднана (detach) або просто зупинений сервер. Очевидно, що користувачі в цей час працювати не зможуть.	Цей спосіб має сенс застосовувати тоді і тільки тоді, коли вже сталася аварія, щоб при спробах відновлення хоча б мати можливість повернутися до того варіанту, з якого почалося відновлення.
Резервне копіювання засобами ОС або гипервизора	Зручний спосіб для середовищ розробки і тестування.	Не завжди дружить з цілісністю даних. Ресурсномісткий спосіб.	Може обмежено застосовуватися для розробки. У продуктовій середовищі практичного сенсу не має.
Резервне копіроавніе засобами MS SQL	Не вимагає простоїв. Дозволяє відновити цілісний стан на довільний момент, якщо заздалегідь про це потурбуватися. Відмінно автоматизується. Економний за часом і іншим ресурсам.	Не дуже компактний формат. Не всі вміють користуватися цим способом в необхідній мірі.	Для продуктових середовищ - основний інструмент.

Основні складності при використанні резервного копіювання вбудованими засобами MS SQL виникають через елементарне нерозуміння принципів роботи. Це пояснюється частково великої лінню, почасти відсутністю простого і зрозумілого роз'яснення на рівні "готових рецептів" (хм, скажімо так, мені не зустрічалося), та ще й посилюється ситуація міфосоветамі "недогуру" на форумах. Що робити з лінню я не знаю, а от пояснити основи резервного копіювання спробую.

Що і навіщо зберігаємо?

Давним-давно в далекій галактиці існував такий продукт інженерно-бухгалтерської думки, як 1С: Підприємство 7.7. Мабуть через те, що перші версії 1С: Підприємства розроблялися для використання популярного формату файлів dbf, Його SQL-версія не зберігала в базі даних достатньо інформації для того, щоб вважати резервне копіювання MS SQL повноцінним, та ще й при кожній зміні структури порушувалися умови роботи повної моделі відновлення, тому доводилося йти на різні хитрощі, щоб змусити систему резервного копіювання виконувати свою основну функцію. Але, з тих пір, як з'явилася версія 8 адміністратори баз даних нарешті змогли розслабитися. Штатні засоби резервного копіювання дозволяють створити повну і цілісну систему резервних копій. Чи не входить в резервне копіювання тільки журнал реєстрації і деякі дрібниці типу налаштувань положення форм (в старих версіях), але це втрата цих даних на функціональності системи в не позначається, хоча безумовно резервні копії журналу реєстрації робити правильно і корисно.

А навіщо взагалі нам потрібно резервне копіювання? Хм. На перший погляд дивне запитання. Ну, напевно, по-перше, щоб мати можливість розгорнути копію системи і по-друге відновити систему при збої? На рахунок першого я згоден, а от друге призначення - перший міф резервного копіювання.

Резервне копіювання - це останній рубіж забезпечення схоронності системи. Якщо адміністратору бази даних доводиться відновлювати продуктову систему з резервних копій, значить, з великою ймовірністю було допущено безліч грубих помилок в організації робіт. Не можна ставитися до резервного копіювання, як до основного способу забезпечення цілісності даних, немає, це скоріше ближче до системи пожежогасіння. Система пожежогасіння необхідна. Вона повинна бути налаштована, перевірена і працездатна. Але якщо вона спрацювала, то це саме по собі є серйозним ПП з масою негативних наслідків.

Для того, щоб резервне копіювання застосовувалося тільки "в мирних" цілях, використовуйте для забезпечення працездатності та інші засоби:

Забезпечте фізичну безпеку серверів: пожежі, затоплення, погане електроживлення, прибиральниці, будівельники, метеорити і дикі тварини - все вони тільки і чекають за рогом, щоб знищити вашу серверну.
Відповідально ставтеся до погроз інформаційної безпеки.
Кваліфіковано вносите зміни в систему і заздалегідь максимально переконайтеся, що ці зміни не призведуть до погіршень. Крім плану внесення змін бажано мати і план "що робити, якщо все піде не так".
Активно використовуйте технології підвищення доступності та надійності системи замість того, щоб потім розгрібати наслідки аварій. Для MS SQL слід звернути на наступні можливості:
- Використання кластерів MS SQL (хоча, якщо чесно, я вважаю, це одним з найбільш дорогих і непотрібних способів зайняти адміністратора БД для систем які не потребують 24х7)
- Віддзеркалення бази даних (в синхронному і асинхронному режимі в залежності від вимог доступності, продуктивності і вартості)
- Доставка журналів транзакцій
- Реплікація засобами 1С (розподілені бази даних)

Залежно від вимог доступності системи і від бюджету, виділеного на ці цілі, цілком можна вибрати рішення, які дозволять на 1-2 порядки скоротити час простою і відновлення при збоях. Не потрібно боятися технологій підвищення доступності: вони досить прості для того, щоб їх вивчити за кілька днів при базових знаннях MS SQL.

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

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

Базова інформація про зберігання і обробки даних MS SQL

Дані в MS SQL зазвичай зберігаються в файлах даних (далі ФД - скорочення не загальновживане, в даній статті буде ще декілька не дуже поширених скорочень) з розширеннями mdf або ndf. Крім цих файлів є ще журнали транзакцій (ЗТ), які зберігаються в файлах з розширенням ldf. Нерідко починаючі адміністратори безвідповідально і легковажно ставляться до ЗТ, як щодо продуктивності, так і по відношенню до надійності зберігання. Це дуже груба помилка. Насправді, скоріше навпаки, якщо є надійно функціонуюча система резервного копіювання та на відновлення системи можна виділити багато часу, то можна зберігати дані на швидкому, але вкрай ненадійному RAID-0, але тоді ЗТ повинні зберігатися на окремому надійному і продуктивному ресурсі (хоча б на RAID-1). Чому так? Давайте розглянемо докладніше. Відразу обмовлюся, що виклад дещо спрощено, але досить для початкового розуміння.

У ФД зберігаються дані сторінками по 8 кілобайт (які об'єднані в екстенти по 64 кілобайт, але це не суттєво). MS SQL не гарантує, Що відразу після виконання команди зміни даних, ці зміни потраплять в ФД. Ні, просто сторінка в пам'яті позначається як "вимагає збереження". Якщо у сервера достатньо ресурсів, то незабаром ці дані виявляться на диску. Причому, сервер працює "оптимістично" і якщо ці зміни відбуваються в транзакції, то вони цілком можуть потрапляти на диск до фіксації транзакції. Тобто в загальному випадку, при активній роботі ФД містить розрізнені шматки недописаних даних і незавершених транзакцій, для яких невідомо, чи будуть вони скасовані або зафіксовані. Є спеціальна команда "CHECKPOINT", яка вказує серверу, що потрібно "прямо зараз" скинути все незбережені дані на диск, але область застосування цієї команди досить специфічна. Досить сказати, що 1С її не використовує (я не стикався) і розуміти, що під час роботи зазвичай ФД не перебуває у цілісному стані.

Щоб впоратися з цим хаосом нам якраз і потрібний ЗТ. У нього пишуться такі події:

Інформація про старт транзакції і її ідентифікатор.
Інформація про факт фіксації або скасування транзакції.
Інформація про всі зміни даних в ФД (грубо кажучи, що було і що стало).
Інформація про зміну самого ФД або структури бази даних (збільшення файлів, зменшення файлів, виділення і звільнення сторінок, створення і видалення таблиць і індексів)

Вся ця інформація пишеться із зазначенням ідентифікатора транзакції в якій вона відбулася і в достатньому обсязі щоб зрозуміти як зі стану до цієї операції перейти до стану після цієї операції і навпаки (виняток - модель відновлення з неповним протоколированием).

Важливо, що ця інформація пишеться на диск відразу. Поки інформацію не записана в ЗТ, команда не вважається виконаним. У нормальній ситуації, коли розмір ЗТ достатнього обсягу і коли він не сильно фрагментований, записи в нього пишуться послідовно невеликими записами (не обов'язково кратні 8 кб). У журнал транзакцій потрапляють дані тільки дійсно необхідні для відновлення. Зокрема нЕ потрапляє інформація про те, який текст запиту привів до модифікацій, який план виконання був у цього запиту, який користувач його запустив та інша непотрібна для відновлення інформація. Певне уявлення про структуру даних журналу транзакцій може дати запит

Select * from :: fn_dblog (, null)

Через те, що жорсткі диски значно ефективніше працюють з послідовної записом, ніж з хаотичним потоком команд на читання і запис і через те, що команди SQL будуть чекати моменту закінчення записи в ЗТ, виникає наступна рекомендація:

Якщо є хоч найменша можливість, то в продуктовій середовищі ЗТ повинні розташовуватися на окремих (від всього іншого) фізичних носіях, бажано з мінімальним часом доступу для послідовного запису і з максимальною надійністю. Для простих систем цілком підійде RAID-1.

Якщо транзакція скасовується, то все вже внесені зміни сервер поверне в попередній стан. Саме тому

Скасування транзакції в MS SQL Server зазвичай триває можна порівняти з сумарною тривалістю операцій зміни даних самої транзакції. Намагайтеся не скасовувати транзакції або приймати рішення про скасування якомога раніше.

Якщо сервер з якихось причин несподівано припинить роботу, то при повторному запуску буде проаналізовано, які дані в ФД не відповідають цілісного стану (незаписані, але зафіксовані транзакції і записані, але скасовані транзакції) і ці дані будуть відкориговані. Тому якщо ви, наприклад запустили перестроювання індексів великий таблиці і провели перезапуск сервер, то при повторному запуску піде значний час на відкат цієї транзакції, причому перервати цей процес можливості немає.

Що відбувається коли ЗТ дійшов до кінця файлу? Все просто - якщо є звільнене місце на початку, то він почне писати в вільне місце на початку файлу до зайнятого місця. Як закільцьованих магнітна стрічка. Якщо місця на початку немає, то сервер зазвичай спробує розширити файл журналу транзакцій, при цьому для сервера виділений новий шматок є новим віртуальним файлом журналу транзакцій, яких у фізичному файлі транзакцій може бути багато, але це вже до резервного копіювання відноситься мало. Якщо у сервера не вийде розширити файл (закінчилося місце на диску або заборонено настройками розширювати ЗТ), то поточна транзакція скасується з помилкою 9002.

Упс. А що ж треба зробити щоб місце в ЗТ завжди було? Ось тут ми підійшли до системи резервного копіювання та до моделей відновлення. Для скасування транзакцій і для відновлення коректного стану сервера в разі раптового вимкнення необхідно зберігати в ЗТ записи, починаючи з моменту старту самої ранньої з відкритих транзакцій. Цей мінімум пишеться і зберігається в ЗТ обов'язково. Незалежно від погоди, налаштувань сервера і бажання адміна. Сервер не може допустити, щоб цієї інформації не було. Тому, якщо відкрити в одному сеансі транзакцію, а в інших виконувати різні дії, то журнал транзакцій може несподівано закінчитися. Найбільш ранню транзакцію можна виявити командою DBCC OPENTRAN. Але це тільки необхідний мінімум інформації. Подальше залежить від моделі відновлення. У SQL Server їх три:

Simple (Проста) - зберігається тільки необхідний для життя залишок ЗТ.
Full (Повна) - зберігається весь ЗТ з моменту останнього резервного копіювання журналу транзакцій. Зверніть увагу, чи не з моменту повного бекапа!
Bulk logged (С неповним протоколированием) - частина (дуже невелика зазвичай частина) операцій записуються в дуже компактному форматі (по суті тільки запис, що змінена така-то сторінка файлу даних). В іншому ідентична Full.

З моделями відновлення пов'язано кілька міфів.

Simple дозволяє знизити навантаження на дискову підсистему. Це не так. пишеться рівно стільки ж, скільки при Bulk logged, тільки вважається вільним набагато раніше.
Bulk logged дозволяє знизити навантаження на дискову підсистему. Для 1С це майже не так. По суті одна з небагатьох операцій, яка може без додаткових танців з бубном підпадати під мінімальне протоколювання - завантаження даних з вивантаження в форматі dt і реструктуризація таблиць.
При використанні моделі Bulk logged якісь операції не потрапляють в резервну копію журналу транзакцій і вона не дозволяє відновити стан на момент цієї резервної копії . Це не зовсім так. Якщо операція відноситься до мінімально протоколюються, то в резервну копію потраплять поточні сторінки з даними і буде можливість "програти" журнал транзакцій до кінця (хоча і не можна на довільний момент часу, якщо є мінімально протоколюються операції).

Модель Bulk logged для баз 1С використовувати майже безглуздо, тому далі ми її не розглядаємо. А ось вибір між Full і Simple розглянемо докладніше в наступній частині.

Структура журналу транзакцій
- Моделі відновлення і управління журналом транзакцій
- Управління журналом транзакцій
Використання резервних копій журналів транзакцій

Принцип дії резервного копіювання в моделях відновлення Simple і Full

За типом формування резервні копії бувають трьох видів:

Full (Повна)
Differential (Диференційна, різницева)
Log (Резервна копія журналів транзакцій, враховуючи, те, наскільки часто цей термін використовується, будемо скорочувати до РКЖТ)

Тут треба не заплутатися: повна модель відновлення і повна резервна копія - істотно різні речі. Для того щоб їх не сплутати, нижче я буду використовувати англійські терміни для моделі відновлення і російськомовні для видів резервних копій.

Повна і диференціальна копія працюють однаково для Simple і Full. Резервна копія журналів транзакцій повністю відсутня в Simple.

Повна резервна копія

Дозволяє відновити стан бази даних на деякий момент часу (на той в який розпочато формування резервної копії). Складається з посторінковою копії використовуваної частини файлів даних і активного шматка журналу транзакцій за той час поки формувалася резервна копія.

Разностная резервна копія

Зберігає сторінки даних, що змінилися з моменту останньої повної резервної копії. При відновленні потрібно спочатку відновити повну резервну копію (у режимі NORECOVERY, приклади будуть наведені нижче), потім можна до отриманої "заготівлі" застосувати будь-яку з наступних різницевих копій, але, звичайно тільки з тих, які зроблені до наступної повної резервної копії. За рахунок цього можна значно знизити обсяг дискового простору для зберігання резервної копії.

Важливі моменти:

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

РКЖТ

Містить копію ЗТ за деякий період. Зазвичай з моменту минулого РКЖТ до моменту формування поточної РКЖТ. РКЖТ дозволяє з відновленої в режимі NORECOVERY копії на будь-який момент часу, що входить в період відновлюваної копії ЗТ, відновити стан на будь-який інший час після цього часу, що входить в інтервал відновлюваної резервної копії. При формуванні резервної копії зі стандартними параметрами, місце в файлі журналу транзакцій вивільняється (до моменту останньої відкритої транзакції).

Очевидно, що РКЖТ не має сенсу в моделі Simple (тоді ЗТ містить лише інформацію з моменту останньої незакритих транзакції).

При використанні РКЖТ виникає важливе поняття - безперервний ланцюжок РКЖТ. Цей ланцюжок може перервати або втрата деяких резервних копій цього ланцюжка, або переклад бази даних в Simple і назад.

Увага: набір РКЖТ по суті марний, якщо він не є безперервним ланцюжком, причому момент початку останнього успішного повного або різницевого резервного копіювання повинен бути всерединіперіоду цього ланцюжка.

Часті помилки і міфи:

"РКЖТ містить дані журналу транзакцій від моменту попереднього повного або різницевого бекапа". Ні це не так. РКЖТ містить і на перший погляд непотрібні дані між попередньою РКЖТ і подальшим повним бекапом.
"Повний або різницевий бекап повинні призводити до звільнення місця всередині журналу транзакцій".Ні це не так. Повний і різницевий бекап не чіпають ланцюжок РКЖТ.
ЗТ потрібно перідіческі чистити вручну, зменшувати, шрінкать.Ні, не треба і навіть навпаки - небажано. Якщо звільняти ЗТ між РКЖТ, то буде порушена ланцюжок РКЖТ, потрібна для відновлення. А постійні зменшення / розширення файлу приведуть до його фізичної та логічної фрагментації.

Як це працює в simple

Нехай є база даних в 1000 ГБ. Кожен день база приростає на 2 ГБ, при цьому змінюється 10 ГБ старих даних. Зроблені наступні резервні копії

Повна копія F1 від 0:00 1 лютого (обсяг 1000 ГБ, стиснення для простоти картини не враховуємо)
- Разностная копія D1.1 від 0:00 2 лютого (об'єм 12 ГБ)
- Разностная копія D1.2 від 0:00 3 лютого (обсяг 19 ГБ)
- Разностная копія D1.3 від 0:00 4 лютого (обсяг 25 ГБ)
- Разностная копія D1.4 від 0:00 5 лютого (обсяг 31 ГБ)
- Разностная копія D1.5 від 0:00 6 лютого (обсяг 36 ГБ)
- Разностная копія D1.6 від 0:00 7 лютого (обсяг 40 ГБ)
Повна копія F2 від 0:00 8 лютого (обсяг 1014 ГБ)
- Разностная копія D2.1 від 0:00 9 лютого (об'єм 12 ГБ)
- Разностная копія D2.2 від 0:00 10 лютого (обсяг 19 ГБ)
- Разностная копія D2.3 від 0:00 11 лютого (обсяг 25 ГБ)
- Разностная копія D2.4 від 0:00 12 лютого (обсяг 31 ГБ)
- Разностная копія D2.5 від 0:00 13 лютого (обсяг 36 ГБ)
- Разностная копія D2.6 від 0:00 14 лютого (обсяг 40 ГБ)

За допомогою цього набору ми можемо відновити дані на момент 0:00 будь-якого із днів з 1 по 14 лютого. Для цього нам потрібно взяти повну копію F1 для тижні 1-7 лютого або повну копію F2 для 8-14 лютого, відновити її в режимі NORECOVERY і потім застосувати разностную копію потрібного дня.

Як це працює в full

Нехай у нас є такий же набір резервних повних і різницевих резервних копій, як в попередньому прикладі. На додаток до цього є наступні РКЖТ:

РКЖТ 1 за період з 12:00 31 січня до 12:00 2 лютого (близько 30 ГБ)
РКЖТ 2 за період з 12:00 2 лютого по 12:00 4 лютого (близько 30 ГБ)
РКЖТ 3 за період з 12:00 4 лютого до 12:00 6 лютого (близько 30 ГБ)
РКЖТ 4 за період з 12:00 6 лютого до 12:00 7 лютого (близько 30 ГБ)
РКЖТ 5 за період з 12:00 8 лютого до 12:00 10 лютого (близько 30 ГБ)
РКЖТ 6 за період з 12:00 10 лютого до 12:00 12 лютого (близько 30 ГБ)
РКЖТ 7 за період з 12:00 12 лютого до 12:00 14 лютого (близько 30 ГБ)
РКЖТ 8 за період з 12:00 14 лютого до 12:00 16 лютого (близько 30 ГБ)

Зверніть увагу:

Розмір РКЖТ буде приблизно постійним.
Резервні копії ми можемо робити рідше, ніж різницеві або повні, а можемо і частіше, тоді вони будуть менше за розміром.
Тепер ми можемо відновити стан системи на будь-який момент з 0:00 1 лютого, коли у нас є найраніша повна копія до 12:00 16 лютого.

У найпростішому випадку нам для відновлення знадобляться:

Остання повна копія до моменту відновлення
Остання разностная копія до моменту відновлення
Все РКЖТ, від момена останньої разностной копії до моменту відновлення

Повна копія F2 від 0:00 8 лютого
Разностная копія D2.2 від 0:00 10 лютого
РКЖТ 6 за період з 12:00 10 січня до 12:00 12 лютого

Спочатку буде відновлена \u200b\u200bF2, потім D2.2, потім РКЖТ 6 до моменту 13:13:13 10 лютого. Але суттєва перевага Full моделі в тому, що у нас з'являється вибір - використовувати останню повну або разностную копію або НЕ останню. Наприклад, якби виявилося, що копія D2.2 була зіпсована, а нам треба відновити на момент до 13:13:13 10 лютого, то для моделі Simple це б означало, що ми можемо відновити дані тільки на момент D2.1. При Full - "DON" T PANIC ", у нас є такі можливості:

Відновити F2, потім потім D2.1, потім РКЖТ 5, потім потім РКЖТ 6 до моменту 13:13:13 10 лютого.
Відновити F2, потім РКЖТ 4, потім РКЖТ 5, потім потім РКЖТ 6 до моменту 13:13:13 10 лютого.
Або взагалі відновити F1 і прогнати все РКЖТ до РКЖТ 6 до моменту 13:13:13 10 лютого.

Як видно, повна модель надає нам більший вибір.

А тепер уявімо, що ми дуже хитрі. І за пару днів до збою (13:13:13 10 лютого.) Знаємо, що збій буде. Ми відновлюємо на сусідньому сервері базу даних повної резервної копії, залишаючи можливість донакативать наступні стану різницевими копіями або РКЖТ, т. Е. Залишили в режимі NORECOVERY. І кожен раз відразу після формування РКЖТ застосовуємо її до цієї резервної базі, залишаючи в режимі NORECOVERY. Ого! Та на відновлення бази даних у нас тепер піде всього 10-15 хвилин, замість того, щоб відновлювати величезну базу! Вітаю, ми заново винайшли механізм доставки журналів, один із способів зниження часу простоїв. Якщо так передавати дані не раз в період, а постійно, то вийде вже віддзеркалення, причому якщо база-джерело чекає поки база-дзеркало оновиться, то це синхронне віддзеркалення, якщо не чекає, то асинхронне.

Детальніше про засоби високої доступності можна прочтітать в довідці:

Високий рівень доступності (компонент Database Engine)
- Загальні відомості про рішення з високим рівнем доступності
- Високий рівень доступності. Взаємодія і спільна робота

Інші аспекти резервного копіювання

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

файлові групи

1С: Підприємство по суті не вміє працювати з файловими групами. Є єдина файлова група і все. Насправді програміст або адміністратор бази даних MS SQL здатний деякі таблиці, індекси або навіть шматки таблиць і індексів покласти в окремі файлові групи (в найпростішому варіанті - в окремі файли). Це потрібно або для того, щоб прискорити доступ до якихось даними (поклавши на дуже швидкі носії), або навпаки, пожертвувавши швидкістю помістити на більш дешеві носії (наприклад, маловикористовувані але об'ємні дані). При роботі з файловими групами є можливість робити їх резервні копії окремо, також окремо можна і відновлювати, але потрібно врахувати, що всі файлові групи доведеться "наздогнати" до одного моменту накочуванням РКЖТ.

файли даних

Якщо приміщенням даних в різні файлові групи керує людина, то коли всередині файлової групи є кілька файлів, то дані по ним розпихує MS SQL Server самостійно (при рівному обсязі файлів - постарається рівномірно). З прикладної точки зору це використовується для розпаралелювання операцій введення-виведення. А з точки зору резервних копій є інший момент. Для дуже великих баз даних в епоху "до SQL 2008" була типовою проблема виділити безперервне вікно для повної резервної копії, та й диск-приймач для цієї резервної копії міг просто її не вмістив. самим простим способом в цьому випадку було робити резервну копію кожного файлу (або файлової групи) в своє вікно. Зараз, з активним поширенням стиснення резервних копій ця проблема стала менше, але все ж цей прийом можна мати на увазі.

Стиснення резервних копій

В MS SQL Server 2008 року з'явилася супер-мега-ультра можливість. Відтепер і назавжди резервні копії можуть бути компрессированного при формуванні на льоту. Це зменшує розмір резервної копії БД 1С в 5-10 разів. А враховуючи, що зазвичай продуктивність дискової підсистеми є вузьким місцем СУБД, то це дає не тільки зниження вартості зберігання, а й ще потужне прискорення резервного копіювання (хоча і підвищується навантаження на процесори, але зазвичай процесорні потужності цілком достатні на сервері СУБД).

Якщо у версії 2008 ця можливість була тільки для Enterprise редакції (яка коштує дуже дорого), то в 2008 R2 ця можливість віддана в версію Standard, що сильно радує.

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

Один файл бекапа - багато нутрощів

Насправді резервна копія це не просто файл, це досить складний контейнер, в якому може зберігатися багато резервних копій. У цього підходу дуже давня історія (я особисто її спостерігаю з версії 6.5), але на поточний момент для адміністраторів "звичайних" баз даних, особливо баз даних 1С, немає будь-яких серйозних причин не використовувати підхід "одна резервна копія - один файл" . Для загального розвитку корисно вивчити можливість складати в один файл декілька резервних копій, але використовувати її швидше за все не доведеться (або якщо і доведеться, то розбираючи завали горе-адміністратора, який цю можливість некваліфіковано використовував).

Кілька дзеркальних копій

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

Приклади систем резервного копіювання

Досить теорії. Пора практикою довести, що вся ця кухня працює.

Налаштування типового резервування сервера через Плани обслуговування (MaintenancePlan)

Цей розділ побудований у вигляді готових рецептів з поясненнями. Цей розділ дуже нудний і довгий за рахунок картинок, тому його можна пропустити.

Користуємося майстром створення плану обслуговування

Налаштування резервування сервера скриптами TSQL, приклади деяких можливостей

Відразу виникає питання, а чого ще треба? Начебто ж тільки що все налаштували і все працює як годинник? Навіщо маятися з усякими скриптами? Плани обслуговування не дозволяють:

Використовувати дзеркальне резервування
Використовувати налаштування стиснення відмінні від налаштувань сервера
Не дозволяє гнучко реагувати на виникаючі ситуації (ніяких можливостей по обробці помилок)
Не дозволяє гнучко використовувати налаштування безпеки
Плани обслуговування дуже незручно розгортати (і підтримувати однаковими) на великій кількості серверів (навіть, мабуть, уже на 3-4)

Нижче наведені типові команди резервного копіювання

Повна резервна копія

Повна резервна копія з затиранням існуючого файлу (якщо є) і перевіркою контрольних сум сторінок перед записом. При формуванні резервної копії отсчтітивается кожен відсоток прогресу виконання

BACKUP DATABASE TO DISK \u003d N "C: \\ Backup \\ mydb.bak" WITH INIT, FORMAT, STATS \u003d 1, CHECKSUM

Разностная резервна копія

Аналогічно - різницева копія

BACKUP DATABASE TO DISK \u003d N "C: \\ Backup \\ mydb.diff" WITH DIFFERENTIAL, INIT, FORMAT, STATS \u003d 1, CHECKSUM

РКЖТ

Резервна копія журналу транзакцій

BACKUP LOG TO DISK \u003d N "C: \\ Backup \\ mydb.trn" WITH INIT, FORMAT

дзеркальне резервування

Часто зручно робити відразу не одну резервну копію, а дві. Наприклад, одна може лежати локально на сервері (щоб була під рукою), а друга відразу формується в фізично віддалене і захищене від несприятливих впливів сховище:

BACKUP DATABASE TO DISK \u003d N "C: \\ Backup \\ mydb.bak", MIRROR TO DISK \u003d N "\\\\ safe-server \\ backup \\ mydb.bak" WITH INIT, FORMAT

Важливий момент, який часто не береться: у користувача, від імені якого запускається процес MSSQL Server повинен бути доступ до ресурсу "\\\\ safe-server \\ backup \\", інакше копіювання завершиться з помилкою. Якщо MSSQL Server запущений від імені системи, то доступ потрібно давати користувачеві домену "ім'я_сервера $", але краще все-таки коректно налаштувати запуск MS SQL від імені спеціально створеного користувача.

Якщо не вказати MIRROR TO, то це буде не 2 дзеркальних копії, а одна копія, розбита на 2 файли, за принципом чергування. І кожна з них окремо буде марна.

Сервери баз даних - одні з ключових в будь-якій організації. Саме вони зберігають інформацію і надають видачу за запитом, і вкрай важливо зберегти БД в будь-якій ситуації. Базова поставка зазвичай включає потрібні утиліти, але адміну, не стикалися до цього з БД, доведеться деякий час розбиратися з особливостями роботи, щоб забезпечити автоматизацію.

Види бекапов баз даних

Для початку розберемося з тим, які взагалі бувають бекапи. Сервер баз даних не є звичайним десктопних додатком, і, щоб забезпечити виконання всіх властивостей ACID (Atomic, Consistency, Isolated, Durable), використовується ряд технологій, а тому створення і відновлення БД з архіву має свої особливості. Існують три різних підходи до створення резервної копії даних, кожен з яких має свої плюси і мінуси.

При логічному, або SQL, бекапе (pg_dump, mysqldump, SQLCMD) створюється миттєвий знімок вмісту бази з урахуванням транзакционной цілісності і зберігається у вигляді файлу з SQL-командами (можна вибрати всю базу або окремі таблиці), за допомогою якого можна відтворити базу даних на іншому сервері. На це потрібен час (особливо для великих баз) для збереження і відновлення, тому дуже часто цю операцію виконувати не можна і її виробляють під час мінімального навантаження (наприклад, вночі). При відновленні адміністратор повинен буде виконати кілька команд, щоб підготувати все необхідне (створити порожню базу даних, облікові записи та інше).

Фізичний бекап (рівня файлової системи) - копіювання файлів, які СУБД використовує для зберігання даних в базі даних. Але при простому копіюванні ігноруються блокування і транзакції, які, швидше за все, будуть неправильно збережені і порушені. При спробі приєднати цей файл він буде в неузгоджену стані і призведе до помилок. Щоб отримати актуальний бекап, базу даних потрібно зупинити (можна зменшити час простою, використавши два рази rsync - спочатку на працюючій, потім на зупиненої). Недолік цього методу очевидний - не можна відновити певні дані, тільки всю базу даних. При старті БД, відновленої з архіву файлової системи, потрібно буде провести перевірку на цілісність. Тут використовуються різні допоміжні технології. Наприклад, в PostgreSQL логи упреждающей журналізації WAL (Write Ahead Logs) і спеціальна функція (Point in Time Recovery - PITR), що дозволяє повернутися до певного стану бази. З їх допомогою легко реалізується третій сценарій, коли бекап рівня файлової системи об'єднується з резервною копією WAL-файлів. Спочатку відновлюємо файли резервної копії файлової системи, а потім за допомогою WAL база приводиться до актуального стану. Це трохи більше складний підхід для адміністрування, але зате немає проблем з цілісністю БД і відновленням баз до певного часу.

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

Barman

Ліцензія: GNU GPL

Підтримувані СУБД: PostgreSQL

PostgreSQL підтримує можливості фізичного і логічного бекапа, додаючи до них ще один рівень WAL (див. Врізку), який можна назвати безперервним копіюванням. Але керувати за допомогою штатних інструментів декількома серверами не дуже зручно навіть адміну зі стажем, а в разі збою рахунок йде на секунди.

Barman (backup and recovery manager) - внутрішня розробка компанії 2ndQuadrant, що надає послуги на базі PostgreSQL. Призначений для фізичного бекапа PostgreSQL (логічний не підтримує), архівування WAL і швидкого відновлення після збоїв. Підтримуються віддалений бекап і відновлення кількох серверів, функції point-in-time-recovery (PITR), управління WAL. Для копіювання і подачі команд на віддалений вузол використовується SSH, синхронізація і бекап за допомогою rsync дозволяє скоротити трафік. Також Barman інтегрується зі стандартними утилітами bzip2, gzip, tar і подібними. В принципі, можна використовувати будь-яку програму стиснення та архівування, інтеграція не займе багато часу. Реалізовано різні сервісні і діагностичні функції, що дозволяють контролювати стан сервісів і регулювати смугу пропускання. Підтримуються Pre / Post-скрипти.

Barman написаний на Python, управління політиками резервного копіювання проводиться за допомогою зрозумілого INI-файлу barman.conf, який може знаходитися в / etc або домашньому каталозі користувача. У постачанні йде готовий шаблон з докладними коментарями всередині. Працює тільки на * nix-системах. Для установки в RHEL, CentOS і Scientific Linux слід підключити EPEL - репозиторій, в якому містяться додаткові пакети. У розпорядженні користувачів Debian / Ubuntu офіційний репозиторій:

$ Sudo apt-get install barman

У репозиторії не завжди остання версія, Для її установки доведеться звернутися до вихідних текстів. Залежностей трохи, і розібратися в процесі нескладно.

Sypex Dumper

Ліцензія: BSD

Підтримувані СУБД: MySQL

Разом з MySQL поставляються утиліти mysqldump, mysqlhotcopy, що дозволяють легко створити дамп бази даних, вони добре задокументовані, і в інтернеті можна знайти велику кількість готових прикладів і фронтенда. Останні дозволяють новачкові швидко приступити до роботи. Sypex Dumper є PHP-скрипт, який дозволяє легко створити і відновити копію бази даних MySQL. Створювався для роботи з великими базами даних, працює дуже швидко, зрозумілий і зручний у використанні. Вміє працювати з об'єктами MySQL - уявленнями, процедурами, функціями, тригерами і подіями.

Ще один плюс, на відміну від інших інструментів, при експорті виробляють перекодування в UTF-8, - в Dumper експорт виробляється в рідній кодуванні. Результуючий файл займає менше місця, а сам процес відбувається швидше. В одному дампі можуть бути об'єкти з різними кодуваннями. Причому легко імпорт / експорт зробити в кілька етапів, зупиняючи процес під час навантаження. При поновленні процедура почнеться з місця зупинки. При відновленні підтримується чотири варіанти:

CREATE + INSERT - стандартний режим відновлення;
TRUNCATE + INSERT - менше часу на створення таблиць;
REPLACE - відновлюємо в робочій базі старі дані, що не затираючи нові;
INSERT IGNORE - додаємо в базу віддалені або нові дані, не чіпаючи існуючі.

Підтримується стиснення копії (gzip або bzip2), Автовидалення старих резервних копій, реалізований перегляд вмісту дамп-файлу, відновлення тільки структури таблиць. Є і сервісні функції з управління БД (створення, видалення, перевірка, відновлення БД, оптимізація, очищення таблиць, робота з індексами і інше), а також файл-менеджер, що дозволяє копіювати файли на сервер.

Управління проводиться за допомогою веб-браузера, інтерфейс з використання AJAX локалізована з коробки і створює враження роботи з настільним додатком. Також можливо запускати завдання з консолі і за розкладом (через cron).

Для роботи Dumper знадобиться класичний L | WAMP-сервер, установка звичайна для всіх додатків, написаних на PHP (копіюємо файли і встановлюємо права), і не буде складною навіть для новачка. Проект надає детальну документацію і відеоуроки, що демонструють роботу з Sypex Dumper.

Є дві редакції: Sypex Dumper (безкоштовно) і Pro (10 доларів). Друга має більше можливостей, все відмінності наведені на сайті.

SQL Backup And FTP

Ліцензія:

Підтримувані СУБД: MS SQL Server

MS SQL Server - одне з популярних рішень, а тому зустрічається досить часто. Завдання резервного копіювання створюється за допомогою середовища SQL Server Management Studio, власне Transact-SQL і командлетів модуля SQL PowerShell (Backup-SqlDatabase). На сайті MS можна знайти просто величезна кількість документації, яка дозволяє розібратися з процесом. Документація хоча і повна, але дуже специфічна, а інформація в інтернеті часто суперечить один одному. Новачкові дійсно спочатку потрібно потренуватися, «набивши руку», тому, навіть незважаючи на все сказане, стороннім розробникам є де розвернутися. До того ж безкоштовна версія SQL Server Express не може похвалитися вбудованими інструментами для резервного копіювання. Для більш ранніх версій MS SQL (до 2008) можна знайти безкоштовні утиліти, наприклад SQL Server backup, але в більшості подібні проекти вже комерціалізувалися, хоча і пропонують всю функціональність часто за символічну суму.

Наприклад, розробка SQL Backup And FTP і One-Click SQL Restore відповідає принципу «налаштував і забув». Володіючи дуже простим і зрозумілим інтерфейсом, вони дозволяють створювати копії баз даних MS SQL Server (включаючи Express) і Azure, зберігати зашифровані і стислі файли на FTP і хмарних сервісах (Dropbox, Box, Google Drive, MS SkyDrive або Amazon S3), результат можна тут же переглянути. Можливий запуск процесу як вручну, так і за розкладом, відправка повідомлення про результат завдання по email, запуск скриптів.

Підтримуються всі варіанти бекапа: повний, диференційний, журнал транзакцій, копіювання папки з файлами і багато іншого. Старі резервні копії видаляються автоматично. Для підключення до віртуального вузла використовується SQL Management Studio, хоча тут можуть бути нюанси і це буде працювати не в усіх таких конфігураціях. Для завантаження пропонується п'ять версій - від безкоштовної Free до навороченій Prof Lifetime (на момент написання цих рядків коштувала всього 149 доларів). Функціоналу Free цілком достатньо для невеликих мереж, в яких встановлено один-два SQL-сервера, всі основні функції активні. Обмежена кількість резервних БД, можливість відправки файлів на Google Drive і SkyDrive і шифрування файлів. Інтерфейс хоча і не локалізована, але дуже простий і зрозумілий навіть новачкові. Потрібно лише підключитися до SQL-сервера, після чого буде виведений список баз даних, слід зазначити потрібні, налаштувати доступ до віддалених ресурсів і вказати час виконання завдання. І все це в одному вікні.

Але є одне але". Сама програма не призначена для відновлення архівів. Для цього пропонується окрема безкоштовна утиліта One-Click SQL Restore, розуміюча і формат, створений командою BACKUP DATABASE. Адміну необхідно лише вказати архів і сервер, на який відновити дані, і натиснути одну кнопку. Але в більш складних сценаріях доведеться використовувати RESTORE.

Особливості бекапа MS SQL Server

Створення резервної копії та відновлення СУБД має свої відмінності, які потрібно враховувати, особливо їх багато при перенесенні архіву на інший сервер. Для прикладу розберемо деякі нюанси MS SQL Server. Для архівування за допомогою Transact-SQL слід використовувати команду BACKUP DATABASE (є і різницева DIFFERENTIAL) і журнал транзакцій BACKUP LOG.

Якщо резервна копія розгортається на іншому сервері, потрібно переконатися, що присутні ті ж самі логічні диски. Як варіант - можна вручну прописати правильні шляхи для файлів бази даних, використовуючи опцію WITH MOVE команди RESTORE DATABASE.

Проста ситуація - бекап і перенесення баз на інші версії SQL Server. Ця послуга підтримується, але в разі SQL Server буде працювати, якщо версія сервера, на якій розгортається копія, така ж або новіше, ніж та, на якій вона створювалася. Причому є обмеження: новішими не більш ніж на дві версії. Після відновлення БД буде знаходитися в режимі сумісності з тією версією, з якою здійснювався перехід, тобто нові функції будуть недоступні. Це легко поправити, змінивши COMPATIBILITY_LEVEL. Можна це зробити за допомогою GUI або SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL \u003d 110;

Визначити, на якій версії була створена копія, можна, переглянувши заголовок файлу архіву. Щоб не експериментувати, при переході на нову версію SQL Server слід запустити безкоштовну утиліту Microsoft Upgrade Advisor.

Iperius

Ліцензія:комерційна, є версія Free

Підтримувані СУБД: Oracle 9-11, XE, MySQL, MariaDB, PostgreSQL і MS SQL Server

Коли доводиться керувати кількома типами СУБД, без комбайнів не обійтися. Вибір великий. Наприклад, Iperius - легка, дуже проста у використанні і одночасна потужна програма для резервного копіювання файлів, що має функцію гарячого резервування баз даних без переривання в роботі або блокування. Забезпечує повний або інкрементальний бекап. Може створювати повні образи дисків для автоматичної переустановки всієї системи. Підтримує резервне копіювання на NAS, USB-пристрої, стример, FTP / FTPS, Google Drive, Dropbox і SkyDrive. Підтримує стиснення zip без обмеження в розмірі файлів і AES256-шифрування, запуск зовнішніх скриптів і програм. Включає досить функціональний планувальник завдань, можливо паралельне або послідовне виконання декількох завдань, результат відправляється на email. Підтримуються численні фільтри, змінні для персоналізації шляхів і налаштувань.

Можливість закачування по FTP дозволяє легко оновлювати інформацію на декількох веб-сайтах. відкриті файли резервуються за допомогою технології VSS (тіньового копіювання томів), що дозволяє виробляти гарячий бекап не тільки файлів СУБД, але і інших додатків. Для Oracle також задіюється засіб організації резервного копіювання і відновлення даних RMAN (Recovery Manager). Щоб не перевантажувати канал, є можливість налаштування смуги пропускання. Управління резервуванням і відновленням проводиться за допомогою локальної та веб-консолі. Всі функції на увазі, тому для налаштування завдання буде потрібно лише розуміння процесу, в документацію заглядати навіть не доведеться. Просто слідуємо підказкам майстра. Також можна відзначити менеджер облікових записів, що дуже зручно при великій кількості систем.

Базові функції пропонуються безкоштовно, але можливість резервування БД закладена тільки в версіях Advanced DB і Full. Підтримується установка від XP до Windows Server 2012.

Handy Backup

Ліцензія:комерційна

Підтримувані СУБД:Oracle, MySQL, IBM DB2 (7-9.5) і MS SQL Server

Одна з найпотужніших систем керування базами даних - IBM DB2, що має унікальні функції по масштабування і підтримуюча безліч платформ. Поставляється в декількох редакціях, які побудовані на одній базі і відрізняються функціонально. Архітектура баз даних DB2 дозволяє управляти практично всіма типами даних: документами, XML, медіафайламі і так далі. Особливо популярна безкоштовна DB2 Express-C. Бекап дуже простий:

Db2 backup db sample

Або снапшот, що використовує функцію Advanced Copy Services (ACS):

Db2 backup db sample use snapshot

Але потрібно пам'ятати, що в разі знімків ми не можемо відновлювати (db2 recover db) окремі таблиці. Є і можливості з автоматичного бекапа, і багато іншого. Продукти добре задокументовані, хоча в російськомовному інтернеті керівництва зустрічаються рідко. Також далеко не у всіх спеціальних рішеннях можна знайти підтримку DB2.

Наприклад, Handy Backup дозволяє виконувати бекап декількох типів серверів баз даних і зберігати файли практично на будь-який носій ( жорсткий диск, CD / DVD, хмарне та мережеве сховище, FTP / S, WebDAV і інші). Можливий бекап баз даних через ODBC (тільки таблиці). Це одне з небагатьох рішень, які підтримують DB2, і до того ж має логотип «Ready for IBM DB2 Data Server Software». Вся процедура виконується за допомогою звичайного майстра, в якому необхідно лише вибрати потрібний пункт і сформувати завдання. Сам процес налаштування настільки простий, що розібратися зможе і новачок. Можна створити кілька завдань, які будуть запускатися за розкладом. Результат фіксується в журналі і відправляється по email. Під час роботи завдання зупинка сервісу не потрібна. Архів автоматично стискається і шифрується, що гарантує його безпеку.

Роботу з DB2 підтримують дві версії Handy Backup - Office Expert (локальний) і Server Network (мережевий). Працює на комп'ютерах під управлінням Win8 / 7 / Vista / XP або 2012/2008/2003. Сам процес розгортання нескладний для будь-якого адміністратора.

sqlcmd -S DECLSERVER \\ SQLGTD -E -Q «declare @s varchar (255) set @ s \u003d 'E: \\ backup \\ GTD_' + convert (varchar (1), datepart (dw, getdate ())) + '. bak 'backup database GTD to disk \u003d @s with init, noformat, skip, nounload »

sqlcmd дозволяє вводити інструкції Transact-SQL, системні процедури і файли скриптів з командного рядка в редактор запитів в режимі SQLCMD,

-S - задає ім'я сервера, server [\\ instance_name];
DECLSERVER \\ SQLGTD - ім'я сервера / ім'я екземпляра, на якому крутиться база;
-E - використовує для з'єднання з SQL server замість імені користувача та пароля довірче з'єднання;
-Q «cmdlinequery« - при запуску програми sqlcmd виконує запит, але вихід з програми по завершенні його виконання не проводиться. Може бути виконано кілька запитів, між якими ставиться крапка з комою. Укладайте запит в лапки, як показано вище;
declare - оголошуємо змінну s, ім'я змінної завжди починається з @, тому @s. У нашому випадку @s - це папка (диск) зберігання резервних копій;
varchar (n) - задає тип змінної @s як строковий з довгою рядки n, в прикладі 255 символів;
set - задає значення змінної @s, В прикладі це папка backup на диску E ( E: \\ backup \\), Далі задається ім'я бекап файлу, де набір функцій convert (varchar (1), datepart (dw, getdate ())) повертає в текстовому форматі з довжиною в 1 символ поточний день тижня (понеділок - 1 , Вівторок - 2 , І т.д.) і додається розширення bak. На виході отримаємо файл з ім'ям GTD_НомерДняНеделі.bak;
backup - створює бекап;
database - вказує на створення бекапа всієї бази;
GTD - в нашому прикладі ім'я бази на SQL-сервері;
to disk - вказує на тип пристрою резервного зберігання, файл жорсткого диска, І вказана змінна @s, Якій присвоєно шлях і ім'я створюваного файлу;
with init, noformat, skip, nounload - вказує на те, що необхідно зробити перезапис даних по колу з перевизначенням заголовків, що дозволить нам мати 7 файлів бекапа на кожен день тижня, перезапису по колу.

При необхідності можна використовувати і інші функції, наприклад стиск, см. Довідку за запитами і функцій Transact-SQL.

Крок 2. Міняємо розширення текстового файлу на.cmd

У підсумку отримуємо файл backupGTD.cmd. Запускати створений командний файл необхідно з тієї машини, де встановлена \u200b\u200bБД MS SQL.

Крок 3. Автоматизуємо даний процес

Розглянемо даний крок на прикладі MS Windows Server 2008: Додати Диспетчер сервера -\u003e Конфігурація -\u003e Планувальник завдань -\u003e Бібліотека планувальника завдань.