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

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

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

У Micrisoft SQL Management Studio вибрати базу, вибрати таблицю, натиснути правою кнопкою миші і вибрати пункти "Script Table as" -> "CREATE TO" -> "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

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

У даній статті буде розказано як вручну зробити повну резервну копію бази даних в за допомогою програми «Середовище Microsoft SQL Server Management Studio».

1. Створення резервної копії

Насправді все досить просто. Запускаємо оснащення " » (« Пуск» — « всі програми» — « SQL Server 2008 R2» — « Середа Microsoft SQL Server Management Studio») І вводимо дані для авторизації.

Після чого в Обозревателе об'єктів розкриваємо вкладку « Бази даних»І кликнемо правою кнопкою миші по тій базі даних, для якої необхідно зробити резервну копію. У контекстному меню виберемо « завдання» ( Tasks) — « Створити резервну копію» ( Back Up ...) .

Запуститься вікно « Резервна копія бази даних» ( Back Up Data Base). Переконаємося, що варто « повна» ( Full), При необхідності поставимо ім'я і опис, а також вкажемо призначення резервної копії. За умовчанням вибраний шлях на жорсткому диску комп'ютера в папку Backup основного розташування баз SQL-сервера. Для того щоб змінити місце розміщення копії, спочатку натиснемо « видалити» ( Remove), Щоб видалити існуюче призначення, а потім « Додати» ( Add...) для додавання нового.

Тут поставимо розташування і ім'я файлу резервної копії і натиснемо « ОК». Таких місць призначень можна задати кілька. В цьому випадку резервна копія буде розбита на рівні частини, кожна частина в зазначеному файлі.

Коли все налаштовано, натискаємо « ОК»І чекаємо завершення завдання. Якщо все зроблено правильно, у вказаній директорії ми знайдемо файл резервної копії бази даних SQL.

2. Відновлення бази даних з резервної копії

Відновлення відбувається за аналогічною схемою. У « Середовищі Microsoft SQL Server Management Studio»Вибираємо базу з якої зроблена резервна копія, Натискаємо по ній правою кнопкою миші, в контекстному меню вибираємо « завдання» ( Tasks) — « відновити» ( Restore) — « База даних…» ( Database ...).

Відкриється вікно « Відновлення бази даних» ( Restore Database). Тут, як джерело вкажемо « З пристрою» ( From device) І виберемо файл резервної копії (створених в пункті 1).

Встановимо прапор « відновити» ( Restore) Навпроти обраної резервної копії. При необхідності, на вкладці « параметри» ( Options), Можна вказати додаткові параметри відновлення, про значення яких можна прочитати.

Після того, як всі налаштування зроблені, тиснемо « ОК»І чекаємо повідомлення про успішне відновлення бази даних.

3. Відновлення резервної копії в іншу базу даних (копіювання даних)

Якщо ж необхідно завантажити дані в базу даних, відмінну від тієї з якою була зроблена резервна копія, То при завантаженні крім дій, описаних в пункті 2, необхідно на вкладці « параметри»(Options) задати імена файлів цієї бази даних і встановити прапор« Перезаписувати існуючу базу даних»(WITH REPLACE).

Чи допомогла Вам ця стаття?

Розглянемо, як організувати дві найбільш часто зустрічаються завдання адміністрування 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).

sqlcmd -S DECLSERVER \ SQLGTD -E -Q «declare @s varchar (255) set @ s = 'E: \ backup \ GTD_' + convert (varchar (1), datepart (dw, getdate ())) + '. bak 'backup database GTD to disk = @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. Запускати створений командний файл необхідно з тієї машини, де встановлена ​​БД MS SQL.

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

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

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

Вступ

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

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

Основні складності при використанні резервного копіювання вбудованими засобами 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, 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 ГБ)

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

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

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

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

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

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

1. Відновити F2, потім потім D2.1, потім РКЖТ 5, потім потім РКЖТ 6 до моменту 13:13:13 10 лютого.
2. Відновити F2, потім РКЖТ 4, потім РКЖТ 5, потім потім РКЖТ 6 до моменту 13:13:13 10 лютого.
3. Або взагалі відновити 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 = N "C: \ Backup \ mydb.bak" WITH INIT, FORMAT, STATS = 1, CHECKSUM

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

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

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

РКЖТ

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

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

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

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

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

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

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