Периферія

Резервне копіювання та відновлення інформації. Резервне копіювання та відновлення файлів. Відновлення файлів із резервної копії файлів після відновлення комп'ютера із резервної копії образу системи

Дорогі друзі, сьогодні ми з вами розглянемо дуже важливу тему: резервне копіювання та відновлення даних. Чому ці два поняття йдуть разом і не окремо? У чому їх особливості, навіщо вони потрібні? На всі ці питання ми відповімо зараз, а потім перейдемо безпосередньо до активних дій.

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

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

  • Інформація з комп'ютера
  • Інформація з планшетів та смартфонів
  • Рекомендації користувачеві

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

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

Інформація з комп'ютера

Так як комп'ютерні дані займають перший рядок у рейтингу важливості серед інших пристроїв, з них ми розпочнемо нашу роботу. Перш за все варто відзначити, що тут теж є невеликий поділ резервної копії за типом інформації, що зберігається: це може бути повна копія операційної системи, копія разом з файлами або окреме зберігання файлів. Для зручності розглянемо приклад для Windows 7, 8.1 та 10 .

Windows 7

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

Натискаємо на «Налаштувати резервне копіювання»

  • Потім перед вами з'явиться діалогове вікно з налаштуваннями архівації. Виберіть свій жорсткий диск і натисніть кнопку «Далі».

Вибираємо розташування архіву

  • У наступному вікні система попросить вас уточнити, що потрібно архівувати. Рекомендується використовувати перший варіант («Надати вибір Windows»), оскільки він зберігає все та регулярно оновлює дані. Зверніть увагу, що тут другий варіант дає користувачеві самому вибрати, що потрібно зберегти. Тобто ви можете поставити свої папки або окремі директорії, якщо повна резервна копія разом із файлами операційної системи вам не потрібна.

Вибір об'єктів для архівації самостійно

  • Далі ми перевіряємо встановлені параметри. Тут можна встановити розклад для автоматичного створення копії за допомогою кнопки «Змінити розклад».

  • Коли все буде встановлено та перевірено, натисніть «Зберегти параметри та запустити архівацію».

Процес виконується

  • Дочекайтеся закінчення процесу, а потім перевірте зовнішній жорсткий диск: чи записалися на нього ваші дані.

Windows 8.1

  • Запустіть панель інструментів у правій частині екрана. Для цього відведіть мишу у правий верхній кут, потім натисніть на «Пошук».
  • Наберіть з клавіатури словосполучення "Історія файлів" без лапок і натисніть Enter. В отриманих результатах натисніть однойменну папку.
  • Ви потрапите у вікно, де потрібно буде натиснути на посилання «Резервна копія образу системи», яка розташована в нижньому лівому кутку вікна.

  • Вибираємо місце зберігання архіву (як ми домовилися вище, це має бути зовнішній жорсткий диск). Натисніть «Далі».
  • Наступне вікно покаже вам обсяг пам'яті, який буде потрібно. Перевірте всі дані та натисніть кнопку «Архівувати».
  • Зачекайте, доки система створить резервну копію Windows на зовнішньому носії інформації. Цей процес може зайняти деякий час, тому не поспішайте панікувати.

Windows 10

  • Запустіть параметри за допомогою кнопки Пуск на панелі завдань.
  • Відкрийте вкладку «Оновлення та безпека».
  • У лівому стовпчику з параметрами натисніть «Служба архівації».
  • За допомогою однойменної кнопки налаштуйте систему автоматичного резервного копіювання.
  • Зверніть увагу, що ви там без проблем можете легко регулювати папки, копії яких будуть створюватися. Це набагато полегшить вашу роботу.
  • Якщо ви хочете створити повну резервну копію разом з операційною системою, а не окремі бібліотеки та директорії, скористайтеся інструкцією для Windows.

Щоб відновити дані, повторіть пункти, перш ніж знайти параметри архівації. А тепер просто виберіть вкладку або пункт «Відновлення» і просто дотримуйтесь інструкцій у діалоговому вікні на екрані монітора. Нічого складного у цьому немає. Звичайно, ми з вами розглянули штатні засоби Windows від Майкрософта. Існують і спеціальні програми щодо аналогічних операцій. Вони можуть бути зручнішими, але в плані безпеки та надійності можуть поступатися цим. Тому рекомендується все ж таки користуватися стандартними утилітами ОС.

Інформація з планшетів та смартфонів

Тут все трохи простіше, тому що також використовуються стандартні програми (наприклад, для iPhone та iPad ми будемо працювати з iTunes). Для всіх гаджетів будь-якої операційної системи процедура виконання резервної копії буде та сама:

  • Підключіть пристрій до комп'ютера або ноутбука. Зачекайте на встановлення відповідних драйверів.
  • Запустіть програму, яка призначена для синхронізації з вашим девайсом. Тобто, якщо у вас iPhone, то відкрийте програму iTunes на своєму ПК.
  • Знайдіть вкладку або пункт «Синхронізація» або «Резервне копіювання». Клацніть по ній і, дотримуючись підказок на екрані, створіть копію.

  • Для відновлення даних у цьому вікні знайдіть однойменну кнопку та натисніть на неї.
  • Під час виконання цих дій комп'ютером не від'єднуйте пристрій від USB. Це може закінчитися програмною поломкою девайса.
  • Зверніть увагу, що можна просто перенести деякі файли зі смартфона або планшета на ПК. Особливо це актуально для власників гаджетів під керуванням операційної системи Android: тут є повний доступ до всіх файлів та папок.
  • Власники iOS-девайсів можуть зберігати тільки фотографії та відео аналогічним чином: зайдіть у «Комп'ютер» і клацніть правою кнопкою миші на вашому пристрої. Натисніть «Імпортувати фотографії та відео». Дотримуючись підказок на екрані, ви можете не тільки зробити імпорт, але й налаштувати його.

Хмарні сховища

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

  • OneDrive для Windows
  • iCloud та iCloud Drive для iOS та MacOS
  • Google диск для Android

Є ще універсальні, які ставляться на будь-який пристрій, незалежно від встановленої ОС:

  • Хмара Mail
  • OneDrive
  • Google диск

Як ви помітили, з усіх сховищ тільки компанія Apple зробила свій продукт доступним лише для своєї системи. Погано це чи добре – вирішувати вам.

  • При використанні зовнішнього жорсткого диска або флешки, подбайте про те, щоб вона мала достатній обсяг вільного простору.
  • Зверніть увагу, що більшість хмарних сховищ мають обмежену пам'ять для безкоштовного доступу. Наприклад, в iCloud Drive вам буде доступно п'ять гігабайт. Щоб розширити її, вам потрібно буде купувати передплату. Якщо у вас не так багато файлів, купувати нічого не потрібно. Можете також скористатися кількома хмарними сховищами.
  • Перевірте створення копій: якщо пам'ять на диску або у хмарі закінчилася, копія не буде створена. Ви ризикуєте втратити деякі дані, що буде дуже сумним наслідком.
  • Якщо ви просто копіюєте деякі файли, то бажано видалити їх з копіюваного девайса для звільнення пам'яті на ньому.
  • Якщо ви хочете зберегти дуже важливі документи, краще зробити дві копії. Наприклад, можете зробити одну на зовнішньому жорсткому диску, а іншу за допомогою програми хмарного сховища.

Підведемо підсумки

Дорогі друзі, сьогодні ми з вами обговорили дуже велику тему: резервне копіювання та відновлення даних. Особливий акцент було зроблено на комп'ютерній інформації, потім ми розглянули загальний принцип створення копії смартфонів та планшетів, а також познайомились із хмарними сховищами. Насамкінець ми дали кілька рекомендацій, щоб ваша робота була максимально продуктивною. Запам'ятайте: збережені дані є запорукою збереження ваших нервів. Якщо ви втратите файли своєї дипломної роботи, яку ви робили кілька тижнів чи місяців, то буде не дуже весело, чи не так? Розкажіть у коментарях, яким службам архівації ви найбільше волієте користуватися і чому.

Традиційно користувачі 1С діляться на дві категорії: тих, хто робить резервні копії*, і тих, хто почне їх робити. Щоб не вчитися на власних помилках, почнемо робити резервне копіювання прямо зараз.

*Якщо ви вже робите резервні копії, ця стаття все одно виявиться вам корисною, оскільки багато з того, що можна знайти і прочитати на тему резервного копіювання в Інтернеті, є помилковим і дуже небезпечним для збереження ваших даних. Якщо ви ІТ-фахівець - переходьте до читання розділу "Резервне копіювання інформаційної бази 1С засобами SQL".

Чи варто взагалі витрачати цей час?

Хіба зараз інформаційна база 1С може якось зламатися? Ламається все: чайники та літаки, ніжка від табуретки та електронний мікроскоп. Важко зламати тільки щось дуже просте, наприклад, чавунну кулю. Але інформаційна база 1С – складний об'єкт і функціонує у складному технологічному середовищі. Рано чи пізно щось станеться, спочатку зовсім незначне, а далі «гвинтик, що відкрутився», викличе каскадну реакцію відмов ПЗ та обладнання, яка в результаті закінчиться великими неприємностями і втратою інформаційної бази.

Файловий варіант інформаційної бази

Почнемо з найпростішого прикладу. У невеликій організації працює конфігурація 1С з файловою інформаційною базою, яку обслуговує системний адміністратор, який напевно все налаштував. Але! Відсутність повідомлень "Не налаштовано резервне копіювання" зовсім не означає, що тепер воно налаштоване. Це може означати також, що це повідомлення просто не відображається. Тому, взявши він відповідальність за надійність і збереження результатів своєї праці, спочатку переконаємося, що інформаційна база саме файлова. Як це зробити наочно показано на ілюстрації нижче. Якщо замість File= написано Srv=, це SQL-база і зверніться до адміністратора баз даних для налаштування резервного копіювання. Якщо файлова база, можна скористатися ручним або автоматичним копіюванням.

Ручний спосіб– створіть резервну копію, як показано на ілюстрації. Перед розвантаженням всі користувачі повинні завершити роботу з інформаційною базою. Вивантаження створює один файл резервної копії з розширенням DT, у якому буде майже все(про це – далі), що є зараз в інформаційній базі, і не буде того, що введеться після цього. Дайте осмислене ім'я файлу (наприклад, «Резервна копія Управління торгівлею на 2017-10-31») та виберіть для його збереження спеціальну папку (наприклад, папка «Резервні копії» у папці «Мої документи»). Використовуючи цей файл, ви можете відновити інформаційну базу до стану, який передував вивантаженню. Для відновлення необхідно використовувати операцію «Завантажити інформаційну базу».





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


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


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

А зараз деякі питання, які не розглянуті у популярних статтях на тему резервного копіювання.

  • Чи все потрапить до резервної копії?

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

  • Чи можна робити резервну копію у процесі роботи?

Стандартний механізм спочатку намагається завершити роботу користувачів. Однак це не завжди вдається, тому операція резервного копіювання може бути виконана і при працюючих користувачах. У цьому випадку передбачається, що ці користувачі не роблять модифікацію даних. Але якщо це не так, гарантії коректності резервної копії немає. Тобто відповідь на це питання – ні, не можна.

  • Як часто робити резервні копії?

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

  • У нас були випадки втрати даних, і ми хотіли б перейти на SQL-варіант інформаційної бази, але це дуже дорого…

Можливо вам підійде безкоштовний варіант MS SQL. Зверніться до нас за консультацією.

SQL-варіант інформаційної бази

Ця частина статті буде цікава фахівцям і тим, хто ще тільки збирається стати ним.

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

З погляду користувача, який живе у понятійному просторі файлових баз, у нас є точки відновленняу вигляді бекапів інформаційної бази, розділених за часом частотою резервного копіювання: якщо ми робимо копії раз на добу, то у разі відновлення втратимо зміни, зроблені в базі максимум за добу або менше. Але в середовищі SQL server і спосіб зберігання/зміни даних, і технології резервного копіювання передбачають «нескінченну» кількість точок, що зливаються в одну безперервну пряму відновлення.Це означає можливість відкату на точку, що безпосередньо передує моменту збою або при необхідності на будь-який момент часу назад. На мові користувача, це рівнозначно створенню резервних копій разів на секунду і менше.

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

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

Невже таке важливе відновлення даних з точністю до секунди?

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

Як отримати копію бази з усіма даними, які знаходились у системі «за секунду до вибуху»

Журнал транзакцій (Transaction log, TLog)

Необхідно записувати в журналі всі дії, які ми збираємося зробити з базою даних, плюс їх точний час (до мікросекунд), а потім виконувати їх. Маючи такий журнал (зберігається на дуже надійному та швидкому носії, обов'язково окремо від самої бази), ми могли б повторити всі операції з початку існування бази даних до довільного моменту відновлення з точністю до мікросекунди. Але у ведення журналу транзакцій є два недоліки: через деякий час зі зростанням бази TLog займатиме дуже багато місця (оскільки він безперервно зростає), а відновлення від «нульового» моменту часу буде виконуватися дуже довго.

Резервні копії журналу транзакцій (TLog backup)

Образно висловлюючись, ми регулярно забиратимемо з журналу всі аркуші і відноситимемо їх у сусідню кімнату (назвемо вилучені аркуші TLog backup), а сам журнал класти пачку нових чистих аркушів, щоб було, куди записувати нові дії з базою. Технічно це виконується так: знімається копія з файлу TLog і записується на архівний диск, після чого всі записи в TLog "стираються" (позначаються як вільні, розмір файлу журналу не змінюється), на "стертому" місці пишеться інформація про нові транзакції. Дуже важливо розуміти – кожна вирвана пачка аркушів, хоч і називається у усталеній термінології Transaction Log backup, є єдинимносієм інформації про дії з базою за цей період, а в самому журналі цієї інформації тепер немає. Тому втрата навіть одного «вирваного листа» поки що абсолютно неприпустима, а термін TLog backupпідступно маскує сутність та призначення даної інформації. Запам'ятайте – це не бекап!Ми розбили журнал на безліч файлів, і інформація в кожному з них не продубльована. Але термін Transaction Log Backup загальноприйнятий, тому й надалі ми використовуватимемо саме його.

Тепер TLog нескінченно не росте, але виникає регламентне завдання – резервне копіювання TLog за розкладом.

Повні резервні копії бази даних (Full database backup, Full backup)

Якщо періодично робити копії всієї бази даних, то для відновлення можна буде взяти найбільш підходящу за часом копію і повторити не всі операції з нульового моменту часу, а лише операції з моменту створення цієї копії до моменту відновлення (як кажуть, "взяти Full backup і накотити на нього TLog").Це значно скорочує час відновлення, особливо якщо база існує вже 5 років. Крім цього, тепер у нас з'явилася можливість видаляти старі Full backup і TLog backup. Насправді, відкат назад з точністю до секунди часто може бути необхідний лише на короткому часовому періоді (наприклад, два місяці тому від поточного моменту для розслідування якихось інцидентів або відновлення бази за секунду до трагічного внесення небажаних змін). Протягом цього періоду ми зберігатимемо безперервний ланцюжок TLog backup. За межами цього періоду можна зберігати лише точки відновлення у вигляді Full backup (і то не всі, а наприклад, лише крапки на перші числа місяця). TLog backup за межами періоду можна тепер видаляти взагалі (очевидно, що їхнє вибіркове видалення та вибіркове зберігання за межами періоду абсолютно безглуздо через порушення безперервності ланцюжка TLog). Так чи інакше виникає регламентне завдання інтелектуального видалення.

Тут виникає така проблема. Представимо базу даних з великою кількістю користувачів та високою інтенсивністю змін. Умовно – 33% часу витрачається на запис та 67% на читання, простоїв немає. Коли ми відновлюватимемо базу, ми можемо писати майже 100% часу, тобто. утричі швидше. Отже, ми можемо три години роботи з базою поновити за журналом за годину. І ця година – максимальний час простою на відновлення, на яке згоден бізнес. Допустимо, Full backup робиться раз на добу. Якщо збій стався за 21 годину від цього моменту – нам доведеться витратити на відновлення за журналом 7 годин, що вже абсолютно неприйнятно. Отже, Full backup треба робити 1 раз на 3 години? На жаль, не завжди це можливо: бази бувають настільки більшими (сотні гігабайт та навіть терабайти), що за такий час Full backup створити просто неможливо. До того ж, часте створення Full backup в робочий час дає додаткове навантаження і сповільнює роботу користувачів, та й зберігати таку кількість даних дуже накладно. Але, в принципі, достатньо і того, що відсутність можливості створити Full backup за прийнятний час повністю ставить хрест на нашій технології резервного копіювання.

Різносні резервні копії (Differential backup, Diff backup)

Ми можемо придумати спеціальну структуру зберігання даних з безперервно зростаючою нумерацією транзакцій та іншими хитрощами, що дозволяють легко зрозуміти різницю між двома станами бази даних. Це дозволить у резервній копії бази даних зберегти не всі дані, а лише відмінності від поточного Full backup від попереднього Full backup. Процедура отримання чергової повної копії буде проста: треба взяти Full backup та накотити на нього Diff backup.Замість збереження одного терабайта даних у Full backup ми зберегли в Diff backup всього десяток мегабайт і отримали можливість робити це досить часто – наприклад, раз на півгодини. Але треба стежити, щоб була в наявності повна резервна копія, інакше недарма різниця.

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

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

  • 5+7=3. Це означає, що маючи Full backup 5 і Diff backup 7 можна відновити базу стан 3. При цьому відсутність 6 ніяк не вплине на можливість відновлення.
  • 5+10+11=3. Того ж результату (відновити у стан 3) можна досягти, якщо до Full backup 5 застосувати всі зміни, зафіксовані в TLogBackup 10 та 11. Так доведеться робити, якщо у нас відсутні 6 та 7 через те, що розкладом було передбачено лише створення 5 та 8 (або якщо 6 та 7 пошкоджені). Але якщо 7 є, то спосіб 5+7 набагато швидше за спосіб 5+10+11.
  • Якщо немає лише 7, то базу в стан 3 можна відновити способом 5+6+11.
  • Якщо розклад такий, що 11 не створювалося, вміст 12 буде наступним: «Додані: Сокирків, Уфимців, Яшин».
  • Журнал транзакцій, на перший погляд, на картинці не представлений, але як ви пам'ятаєте, TLog backup – це не бекап, а журнал транзакцій за певний період. Зверніть увагу, що поява нових прізвищ у журналі передує їх появі у базі даних.
  • Якщо не створювати резервні копії журналів транзакцій, вміст TLog в момент 12 буде наступним: «Додані:», а далі список прізвищ 4 (тобто зафіксовано всі дії). Якщо резервні копії створені, як на картинці, вміст журналу транзакцій в момент 4, як і в момент 8, буде наступним: «Жодних дій поки не проводилося».



Резервне копіювання заключного фрагменту журналу транзакцій

Якщо не йдеться про системи високої доступності, то у разі збою потрібна ще одна вже не регламентна, а ручна операція – створення останнього TLog backup. Якщо неможливо, тобто. журнал пошкоджено разом з базою або разом із сервером – відновлення можливе лише до останнього TLog backup, а не на останню секунду. Тобто. поставлена ​​спочатку мета не буде досягнуто.

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

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

Full recovery model (працює лише з регламентними завданнями та під контролем адміністраторів)

Ми описали повну модель відновлення бази даних Full recovery model. Для особливих випадків у MS SQL Server існує проста модель відновлення (Simple recovery model) та модель з неповним протоколюванням (Bulk-logged). Full recovery model передбачає регулярне виконання завдань обслуговування бази даних, а також контроль регулярності та результатів виконання завдань з боку адміністратора. Це передбачає існування складного інструментарію проектування плану обслуговування (Maintenance Plan), який слід вивчити.

Перейдемо до практики

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


Потрібно дозволити цей функціонал виконанням SQL-скрипта (New Query на панелі інструментів, набрати скрипт, Execute на панелі інструментів). У разі успішного виконання скрипта ви побачите відповідні повідомлення в нижній частині вікна зі скриптом.


Текст цього скрипта для копіювання/вставки:

sp_configure "show advanced options", 1; GO RECONFIGURE; GO sp_configure "Agent XPs", 1; GO RECONFIGURE GO

Реальний план обслуговування

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








В браузері об'єктів ми бачимо, що на SQL сервері налаштовано два плани обслуговування (Основний план, Тестовий план). Основний план складається з чотирьох підпланів з різним розкладом (Shedule):

  • Щотижневе обслуговування
  • Диференціальний бекап
  • Бекап ЖТ

У сфері дизайну завдань бачимо завдання. Процес конструювання плану полягає у перетягуванні задач з палітри Toolbox, встановлення параметрів задач та малюванні стрілок між завданнями. Завдання можуть мати довільний опис у галузі дизайну, відповідність між завданням на плані та завданням на палітрі можна встановити за іконками. Наприклад, завдання "Помилка цілісності" - це завдання "Notify operator task" на палітрі (іконка "людина").

Це блок-схема?

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

Паралелізм та обмеження

Єдине, що його зупиняє наявність обмежень. Завдання не може бути запущене, поки не «здійснилися» вхідніу ній стрілки (обмеження, restrictions). Колір стрілки позначає тип завершення завдання, що впливає. Вхідна зелена стрілка позначає для залежного завдання обмеження «запустити тільки у разі успішного виконання завдання, що впливає», чорна – «запустити тільки після завершення впливає завдання (Completion)», червона – «запустити тільки у разі помилки у впливає задачі (Failure)».

Тип лінії (суцільна або пунктир) позначає логічний оператор AND або OR для обчислення підсумкового обмеження кількох вхідних стрілок. Цей оператор змінюється в діалозі Precedence Constraint Editor (подвійний клік за будь-якою зі стрілок). Суцільні стрілки мають збутися все, з пунктирних має збутися хоча б одна – тоді залежне завдання одразу буде запущено. Колір кожної вхідної стрілки можна змінювати незалежно (правий клік, Success/Failure/Completion). Тип лінії можна змінити тільки для всіх вхідних стрілок одразу (подвійний клік, діалог Precedence Constraint Editor). Спочатку починають одночасно виконуватися всі завдання, які не мають обмежень. Як тільки завершується чергове завдання, перевіряються всі залежні від неї завдання і одночасно запускаються виконання тих, у яких підсумкове значення обмежень стало достатнім для прийняття рішення про запуск.

Інформації у попередньому абзаці достатньо розуміння загального механізму виконання сервером SQL завдань плану обслуговування. Тепер розглянемо питання, що мають прикладне значення.

Дивний розклад

Дивний час виконання завдань пояснюється різницею 4 години між часовим поясом серверів та часовим поясом розробників. Діапазон можливого часу роботи розробників з 9:00 до 21:00 тому підплан «Бекап ЖТ» виконується щогодини з 10:00 до 21:00, фіксуючи зміни щогодини (о 9:00 цих змін ще немає). У перекладі на часовий пояс серверів це з 14:00 до 01:00 ночі, що і вказано в розкладі.

При вказівці часу можна перескакувати через північ, це правильно працює. Виглядає трохи незвично. Інші планувальники, щоб уникнути труднощів з розумінням часу закінчення наступної доби, запитують тривалість виконання завдання – «протягом Х годин».


Якщо за повним бекапом негайно слідує бекап ЖТ - можна бути на 100% впевненим у тому, що план створений майстром планів обслуговування (ніколи не використовуйте його, він не створює нічого, крім сміття) або адміністратором низької кваліфікації, який вважає пару Full backup + TLog backup , Виготовлену одночасно, деяким обов'язковим комплектом для відновлення. Адже це – незалежні завдання, що виконуються за різними розкладами.

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

Якщо видалення старих бекапів виконується безумовно, може виявитися, що нові бекапи не створюються, а старі видаляться повністю. Якщо видалення старих бекапів розкидається в залежності від типу бекапу за різними підпланами – виходить майже те саме. Припустимо, перестав спрацьовувати повний бекап. При цьому перестало видалятися старих повних копій. Але підплан Бекап ЖТ нічого про це не знає і продовжує видаляти застарілі бекапи ЖТ. Через деякий час у нас не буде не тільки безперервної прямої відновлення, але і навіть точок відновлення в актуальному вікні: останній зроблений повний бекап зроблений занадто давно, а бекапи ЖТ, що зберігаються, останнім часом абсолютно марні, т.к. немає жодного повного бекапу всередині їхнього безперервного ланцюжка.

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

*

*Зверніть увагу на завдання значок fx

Кожне завдання має властивості, частину з яких можна побачити в діалозі налаштування задачі (подвійний клік), а повний список – у діалозі властивостей (правий клік, Properties). Також у завданнях є властивість Expressions, яка дозволяє сформувати таблицю властивостей та відповідних їм виразів SQL для обчислення значень властивостей «на льоту». Практична користь з цієї можливості наступна. Напевно, вам доводилося бачити т.зв. "батники" для того, щоб видалити все, крім бекапів на перші числа, або навпаки, щоб перед видаленням бекапів скопіювати бекапи на ці числа в якесь інше місце.


Подібні завдання не потребують зовнішніх інструментів та вирішуються штатними засобами MS SQL. Розширення файлу повної резервної копії за першими числами можна зробити MNT, а решти днів – BAK. Отже, завдання очищення може видаляти BAK старше 1 місяця, а MNT зберігати більш тривалий час, видаляючи їх, наприклад, через 1 рік.


При відкритті діалогу налаштування завдання «Повний бэкап БД» ви побачите розширення файлу BAK чи MNT залежно від дати.




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

Розглянемо закономірне питання: а чи все коректно працюватиме у забороненому завданні? Як на таку заборону відреагують червоні, чорні та зелені стрілки?

При написанні складних планів обслуговування виникає завдання налагодження і практичні потреби, що випливають з неї:

  • Не виконувати довгу задачу фактично, але вважати її умовно виконаною, зберігши її вплив як стрілок інші завдання;
  • Моделювання помилкового виконання завдання.

Для першого у MS SQL є механізм заборони фактичного виконання завдання: правий клік по задачі, Disable. При цьому завдання стане сірим, фактично виконуватися не буде, але вважатиметься як завершеним, так і виконаним (працюватимуть чорні та зелені стрілки). Якщо ми хочемо змоделювати помилкове виконання, то у вікні властивостей задачі треба встановити властивість задачі ForceExecutionResult значення Failure. Не переплутайте цю властивість з властивістю ForcedExecutionValue в іншому розділі.


Реалізація умови ((A or B) and C) для обмежень задачі або фіктивні задачі, які зовсім не фіктивні

Обмеження можуть бути об'єднані або оператором AND або оператором OR. Це означає, що на ілюстрації нижче пунктирні стрілки Completion не можна провести безпосередньо до завдання «Сповістити про завершення помилок». Рішення полягає у створенні проміжної задачі «Були помилки», що акумулює результат чорних пунктирних стрілок. Завдання є SQL-скриптом з однієї інструкції go, тобто, здавалося б, нічого корисного не робить.



Але насправді вона збирає вхідні обмеження і служить джерелом обмежень для інших завдань, будучи таким чином важливою точкою управління, через яку проходить виконання сценарію. Даний прийом із фіктивним завданням можна використовувати і в інших ситуаціях. Наприклад, у вашому сценарії немає потреби переводити бази в стан офлайн і потім повертати стан назад. Але просто так завдання «Онлайн баз, що не бекапуються» з підплану не видалити, вона є важливою точкою виконання, збираючи вхідні обмеження і служачи джерелом вихідних. У такому разі треба замінити це завдання фіктивним сценарієм.

Асинхронність виконання

У конструкції на ілюстрації вище може виникнути "квантовий парадокс", коли слідство випереджає причину. Справді, якщо одне з завдань, що впливають, наприклад, «Помилка цілісності» дала сигнал до запуску залежного завдання, чекати результату від інших впливових завдань вже не має сенсу, це все одно не вплине на те, що залежне завдання «Були помилки» треба запускати. Тому вона одразу ж виконається. Ще через деякий час може статися так, що спрацює та завершиться завдання «Помилка бекапу ЖТ». Вона могла б спричинити запуск «Були помилки», але ця подія вже відбулася раніше. У нашому підплані так і задумано, але такі асинхронні ефекти слід мати на увазі, щоб не отримати несподівані результати. Наприклад, при вимірі загального часу виконання підплану обслуговування за допомогою завдання «повідомлення оператора» на початку та наприкінці.

Що це таке?


Це перша і одна з останніх завдань, що є скриптами SQL. Справа в тому, що в контурі розробки часто є копії історичних систем дуже великого обсягу. Вони призначені для ознайомлення з веденням історичного обліку, є джерелом даних в операціях міграції. Дані у них практично не змінюються. Оригінали баз знаходяться в поточному контурі продуктивного замовника, копії цих систем завжди можуть бути отримані за запитом. Бекапити цей гігантський обсяг інформації – марно витрачати ресурси. У параметрах задач, що створюють бекапи, гарною практикою є вказівка ​​в задачах бекапу параметра «All» замість перерахування конкретних баз даних (це дозволяє уникнути типової помилки «базу створили, а список бекапу включити забули»). А якщо так, необхідний механізм якогось виключення деяких особливих баз з безлічі All. Саме це робить перший скрип – переводить такі бази в стан OFFLINE. Другий скрипт виконує зворотну операцію. При цьому в параметрах задач бекапу або реіндексування ставиться параметр «Ігнорувати бази у стані OFFLINE», інакше виникне помилка завдання.



Паралельно чи послідовно

У підплані «Щоденний повний бекап» найпершою виконується завдання «Оффлайн баз, що не бекапуються», т.к. це єдине завдання, яке не має обмежень. Нижче за неї ми бачимо збудовану послідовністьвиконання завдань, що є основним стрижнем підплану «Щоденний повний бекап».

Як причини послідовного виконання назвемо, припустимо, бажання не перевищити навантаження сервера SQL під час обслуговування і наочність сприйняття плану. Зазвичай, за рахунок великого нічного вікна з перервою в роботі користувачів, послідовне виконання не стає проблемою. Але можуть бути ситуації, коли з базою працює багато користувачів з різних часових поясів, і вікно обслуговування стає дуже невеликим. Якщо послідовне виконання завдань не вписується у вікно обслуговування, їх доведеться розпаралелювати. Це можна зробити стрілками, що виходять з «Оффлайн баз небекапів» до кожноїосновне завдання, а потім сходяться до «Онлайн небекапованих баз». Дві сірі завдання повинні виконуватися послідовно один до одного. Результат розпаралелювання на ілюстрації нижче. Досягаються поставленої мети, але значно втрачається наочність:


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



Паралелізм усередині стандартних завдань Backup Database та Check Database Integrity та інтерпретація результату їх виконання

Завдання «Створення резервної копії» та «Перевірка цілісності бази даних» працюють у загальному випадку зі списком баз даних. Чи працюватимуть вони послідовно з кожною базою даних або виникне безліч паралельних завдань обслуговування кожної бази? Виконаємо подвійний клік по задачі, у діалозі, що відкрився, натиснемо кнопку «View T-SQL». Ми бачимо, що у скрипті, який генерується та виконується сервером SQL, інструкції створення резервних копій BACKUP DATABASE розділені інструкціями GO, а отже, ці процеси створення резервних копій виконуватимуться паралельно. Результат відноситься не до пакетів, а до завдання загалом. Якщо виникла помилка в завданні хоча б з однією базою – загалом завдання вважатиметься виконаним помилково, якщо помилок немає – загалом завдання вважається виконаним успішно.



Розклад завдань обслуговування (ключове питання, що часто вважається другорядним)

Згадаймо основні завдання плану обслуговування бази даних повної моделі відновлення:

  1. Завдання Full backup
  2. Завдання Diff backup
  3. Завдання TLog backup

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

Головне, з чого треба виходити, це допустиме вікно втрати даних (Recovery point objective, RPO) + час відновлення (Recovery time objective, RTO). Ці показники, у свою чергу, визначають апаратну архітектуру, застосовувані технології та періодичність виконання завдань.

Періодичність TLog backup

Періодичність TLog backup залежить від RPO. Типова періодичність завдання TLog backup для продуктивних баз – від ½ до 1 часу RPO на всьому добовому інтервалі часу внесення змін до бази (включаючи інтервали часу, на яких відбуваються зміни регламентними завданнями та разовими обробками у неробочий час). Для продуктивних баз характерним є внесення змін протягом 24 годин. Якщо для такої бази RPO=1 година, то бекап журналів транзакцій має виконуватися цілодобово кожні 30-60 хвилин. Але не виключені випадки, коли через специфіку системи можна обмежитися лише інтервалом робочого часу, наприклад з 10 до 18, з понеділка по п'ятницю, а також більшою чи меншою частотою.

Для непродуктивних баз (в середовищі розробки) більш доцільним може бути використання простої моделі відновлення, де це завдання взагалі відсутнє. Незважаючи на те, що у численній літературі та офіційній документації декларується, що використання спрощеної моделі не дає виграшу у продуктивності (т.к. TLog все одно ведеться), практично це негаразд.Час виконання часто виконується операції приміщення змінених об'єктів конфігурації 1С сховище при використанні спрощеної моделі відновлення скорочується в рази, а сумарний виграш за часом різко збільшує швидкість розробки. При цьому з періодичністю від 1/2 до 1 часу RPO треба створювати вже Diff backup. Цей метод можна використовувати для продуктивних бек-офісних систем з низькою інтенсивністю зміни, де є можливість повторного введення даних, що знаходилися у вікні RPO і втрачених в результаті збою.

Взаємопов'язана періодичність Full backup та Diff backup

Періодичність обох завдань загалом підбирається таким чином, щоб можна було дотриматися RTO. Якщо інтенсивність внесення змін така, що дозволяє робити повні бекапи щомісяця, диференціальні бекапи щодня, і навіть 29-го числа відновлення відбувається у межах RTO – чому ні. Якщо інтенсивність внесення змін така, що за такої періодичності завдань час відновлення стає неприйнятним – можливо, потрібна повна копія на початок дня та кілька диференціальних бекапів протягом доби.

p align="justify"> Періодичність завдання Diff backup також залежить від обсягу Diff backup в порівнянні з Full backup. Якщо за обраної періодичності Diff backup його розмір починає перевищувати половину розміру Full backup, подальше створення Diff backup стає недоцільним, у цій точці треба створювати черговий Full backup. Однак варто пам'ятати, що це співвідношення слід ігнорувати на відносно нових базах даних – згодом обсяг щоденних змін складатиме невелику (тобто допустиму для Diff backup) частину загального обсягу даних, а 95% обсягу займатимуть історичні дані.

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


Для баз, що часто оновлюються, пропонується робити Full backup по неділях, а TLog backup 1 раз на добу. Вікно втрати даних (RPO) = 1 добу – це неприпустимо багато. При цьому експерт переконаний, що це і є найкращий спосіб запобігти будь-якій втраті даних. Неприпустимо великим буде також час відновлення у суботу, адже треба буде застосувати до Full backup зміни за 6 днів, а інтенсивність змін у базі більша.


Тут щодня з понеділка по п'ятницю робиться бекап ЖТ та Shrink ЖТ (Текст «копії БД» у колонці «Опис» – явна друкарська помилка, тому що в колонці «дії» чітко вказана операція – бекап ЖТ). Якщо ви повернетеся до нашого підплану «Щоденне обслуговування», то побачите, що завдання усічення ЖТ носить промовисту назву «Shrink не робити» і є забороненим завданням (сіра). Пошуковий запит "чи треба робити шринк" допоможе уточнити інформацію.

Спускаємося на рядок нижче і бачимо, що після кожного Diff backup видаляються TLog backup – це добровільна відмова від безперервної прямої відновлення (ключова мета всієї системи резервного копіювання) та перехід до точок відновлення. Крапки відстоять одна від одної на добу. Це означає, що вікно втрати даних – доба (RPO=24 години).

Спускаємося на останній рядок і знаходимо найбільшу помилку всього плану. Якщо сталося випадкове чи зловмисне пошкодження даних, то дані дуже надійно зберігаються, але є марними. Уявімо випадок, коли в суботу виходить програміст, щоб розібратися з проблемою «звіти видають повну нісенітницю». О 18:05 він розуміє, що наявність проблеми пов'язана з тим, що повністю спотворені дані ключових регістрів, причому журнали кажуть, що це сталося в п'ятницю після обіду. В цей момент часу у нього існує база даних, дані в якій неправильні, і один єдиний повний бекап, зроблений 5 хвилин тому, дані в якому також неправильні. Решта начисто видалено, т.к. було успішно створено повний бекап. Цей план обслуговування – чемпіон за кількістю зроблених помилок.


На ілюстрації вище – план початкового рівня, створений початківцем за допомогою майстра Maintenance Plan Wizard і не вирішує жодних завдань. У ньому є поширена помилка: не можна ставити завдання створення повної резервної копії у залежність від результатів перевірки цілісності. При падінні бази даних краще мати резервну копію з двома «битими» посиланнями в базі, ніж нічого не мати. Порівняйте з тим, як зроблено у підплані «Щоденний бекап» – порушення цілісності інформує оператора, але не перешкоджає створенню бекапів.

Особливості відновлення – як не втратити дані

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

Оскільки ці «особливості» ніде не описані, давайте заповнимо цю прогалину. Розглянемо типове завдання відновлення продуктивної бази за станом певний час (джерело, ZUP3ENERGO на ілюстраціях) в індивідуальну базу програміста (приймач, ZUP_SUV на ілюстраціях) для розслідування інциденту. Описуючи різні «особливості» поведінки різних версій SQL сервер, під терміном «нові версії» ми маємо на увазі реліз 13.0.4457.0, а терміном «старі версії» – реліз 11.0.3156.0.

Перша дія- Правою кнопкою по базі-приймачу, Tasks, Restore, DataBase. І відразу ж у діалозі Restore Database (ілюстрація нижче) ми бачимо жовтий знак небезпеки: буде зроблено резервну копію заключного фрагменту журналу транзакцій бази-джерела. Звичайно, насправді мова повинна йти про базу-приймача і логіка тут мала б бути наступною: перш ніж знищити поточний вміст відновленням, давайте про всяк випадок остаточно зафіксуємо те, що є зараз. Це дозволить відкотити поточне відновлення назад, виконавши ще одне відновлення на точку перед відновленням. Операція, здавалося б, корисна і нічого небезпечного в ній немає, якби справді йшлося про приймача. Але це не просто помилка у повідомленні, tail-log backup помилково виконується для джерела. Це можна перевірити експериментально, натиснувши кнопку Script та подивившись код.


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

Тепер давайте розберемося, що насправді може бути джерелом. У діалозі видно, що джерелом може бути Database та Device. Чи треба пояснювати, що база даних не може бути джерелом даних на довільний момент часу в минулому. Джерелом можуть бути бекапи бази даних. Тому потрібне пояснення опцій.

  • Джерело Database – все безліч файлів, що містить у собі бекапи бази-джерела та її журналів згідно з реєстром бекапів,який ведеться у системних таблицях SQL сервера. «Згідно з реєстром бекапів» – вкрай важлива фраза для розуміння механізму операції. Вона означає, що навіть якщо в даний час якийсь файл відсутній на диску, він може бути врахований у плані відновлення (зафіксований у реєстрі) і з'явиться в списку Backup sets to restore. Помилка виникне лише на стадії відновлення і якщо це файл Diff backup або TLog backup – база залишиться у стані, непридатному для використання.Щоб цього не сталося, перевіряйте можливість відновлення кнопкою «Verify backup Media».
  • Джерело Device – довільний набір файлів. Справа в тому, що історія бекапів може бути очищена. Або бекапи створювалися на іншому сервері SQL і тому не зареєстровані у реєстрі бекапів на цьому сервері. Тому є можливість явної вказівки довільного набору файлів. Вказати можна надлишковий для відновлення набір файлів (наприклад, за багато днів – SQL сервер наступного кроку підбере лише необхідні).

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

  • Ефект 1. MS SQL відразу змінює Destination на базу даних, вказану в Source. Тому Destination треба повернути назад. Якщо ви не помітите цього, база буде мовчки перезаписана, і навіть знятий прапор "Overwrite the existing database" на закладці Options не зможе її захистити;
  • Ефект 2. Перемикаємось на закладку Files і бачимо – замість приймача MS SQL Server хоче перезаписати джерело (див. наступну ілюстрацію). Необхідно руками вбити імена файлів бази-приймача та її журналу, інакше буде втрачено джерело (див. далі четверту дію).

Третя дія.Після вибору набору файлів як джерело необхідно уточнити час (Restore to, кнопка Timeline). Уточнення моменту часу дозволяє з вихідної множини файлів, що визначаються джерелом (Source), вибрати конкретний набір (Backup sets to restore), необхідний відновлення на вказаний час. Стає очевидною ще одна безглуздість, присутня навіть у останніх версіях MS SQL: опція «Restore to» і кнопка TimeLine намальовані в діалозі зовсім не там. Вони, безумовно, належать до джерела, а чи не до приймача. Ця помилка не буде виправлена ​​ніколи їй більше 10 років, тому до неї треба просто звикнути. Будьте також дуже уважні при ручному введенні часу без використання лінійки: навіть останні версії SQL сервера «з'їдають» перше введення числа місяця, тому число необхідно буде ввести двічі.

Четверта дія.



П'ята дія.Перемикаємось на закладку Options. Поставте опцію перезапису бази даних, зніміть опцію створення заключного фрагмента ЖТ, увімкніть опцію «закрити існуючі підключення до бази-приймача», якщо вона доступна:



Шоста дія.Після відновлення із «чужого джерела» відновлена ​​база (ZUP_SUV) отримає чуже логічне ім'я (ZUP3ENERGO). Його необхідно повернути назад у діалозі властивостей бази даних (правий клік по базі, Properties). Якщо цього не зробити, то настануть дуже неприємні наслідки.


Успіхів вам і вашим даним!

Доброго часу доби, шановні читачі, з вами Трішкін Денис. Комп'ютер – складна інженерна система. Як і інші, вона може іноді виходити з ладу. А тому важливо стежити за збереженням інформації. Для цього можна використовувати різні інструменти, одним з яких є вбудована програма – резервне копіювання. У разі виходу з експлуатації системи ця функція допоможе швидко все повернути на свої місця. Отже, як зробити відновлення Windows 7 із резервної копії правильно?

Що таке резервне копіювання та відновлення?( )

Операційки від компанії Microsoft мають інструмент, що дозволяє створювати копію інформації, і при необхідності скористатися нею. Іноді це пов'язано з проблемами Windows. В інших випадках можуть виникнути проблеми жорсткого диска. Тому багато хто рекомендує переносити інформацію на інший носій, будь то переносний вінчестер або CD-диск. Сьогодні технології дозволяють розмістити копію навіть у хмарних інструментах.

Створення точки відновлення( )

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

Як створити потрібну точку? Для того, щоб потрапити до меню, необхідно в « Пусці» у рядку пошуку написати: «». Крім того, сюди можна зайти через Панель управління», обравши « Показувати всі піктограми».

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

Отже, нам потрібно:

    1 У пошуку написати «» вибрати відповідний компонент.

    збільшити

    2 Відобразиться вікно з активною вкладкою «».

    3 Вибираємо диск та натискаємо « Створити».

    збільшити

    4 Вводимо опис, щоб вам далі було зрозуміло під час використання.

    збільшити

    5 Почнеться процес, після якого з'явиться повідомлення про успішне закінчення.

    збільшити

    збільшити

Важливо! Таким чином копіюються всі дані реєстру.

Створення резервної копії особистих даних( )

Нам потрібно:

    1 У вікні натиснути " ".


    збільшити

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


    збільшити

    Важливо! Якщо вибрано Windows, копіюються стандартні папки ОС, драйвера та бібліотеки. Крім того, при деяких налаштуваннях створюється образ головного розділу, якщо комп'ютер повністю вийде з ладу.

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


    збільшити


    збільшити

    4 Після цього програма покаже огляд плану копіювання. Ми виставляємо слушний час і зберігаємося. Запускається процес.

    Цікаво! Багато хто хоче знати, де зберігаються такі копії. Вони розташовуються на основному диску \WindowsImageBackup\ім'я_комп'ютера\. За бажанням переміщуються в потрібне місце. При цьому їх можна видалити, як інші звичайні файли. Крім того, це робиться безпосередньо через сам майстер поновлення.


    збільшити


    збільшити

Створення диска для відновлення( )

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

Отже, нам потрібно:

    1 Натиснути « Win+R».

    2 У вікні « Виконативводимо sdclt».

    3 Зліва клацаємо по «».


    збільшити


    збільшити


    збільшити


    збільшити

    5 У деяких випадках з'являється запит на використання мультизавантажувального диска Windows. Це вказує на те, що файли не вдається знайти на комп'ютері. Потрібно встановити відповідний диск.

Відновлення системи( )

Як відновити працездатність ОС? Все просто, потрібно:

Потрібно відзначити, що так відбувається і відновлення реєстру, а тому робити будь-які додаткові рухи в цьому напрямі не потрібно.

Відновлення файлів із резервної копії( )

Якщо особиста інформація з якихось причин загубилася, і ви хочете повернути її повноцінну працездатність, потрібно скористатися відповідним інструментом:

    1 Заходимо до «». Пишемо у пошуку цю фразу і вибираємо відповідний елемент.

    збільшити

    2 Вибираємо знизу "".


    збільшити

    3 З'являється вікно, де ми вказуємо на потрібний вміст. Клікаємо «». А потім " Далі».


    збільшити

    4 Тепер вибираємо, куди саме поновити інформацію.

    збільшити

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

Відновлення з диска( )

Щоб повернути потрібну інформацію з окремого переносного пристрою, необхідно:

    1 Підключіть відповідний носій до комп'ютера.


    збільшити

    2 Перезавантажити.

    3 Входимо до BIOS. Для цього відразу після появи першої інформації на моніторі натискаємо потрібну клавішу (залежно від материнської плати може бути: Del, F1, F2, F8 або інші кнопки).


    збільшити

    4 Налаштовуємо завантаження, як із CD/DVD або флешки.


    збільшити

    Як доповнення до цього пункту раджу скористатися моєю статтею

  1. 5 Зберігаємось і перезавантажуємося (можна просто натиснути F10 і підтвердити дію).


    збільшити

    6 Потім з'явиться вікно пожвавлення з різними параметрами. Вибираємо необхідний.


    збільшити

Опис параметрів відновлення( )

    1 Відновлення запуску – допомагає повернути важливі дані, що використовуються операційною системою під час завантаження.

    2 Відновлення системи – замінює файли, які використовуються ОС. При цьому ніяк не впливає на дані користувача, типу музики, фотографій та іншого. Цю дію не можна буде скасувати. Але в майбутньому можна вибрати іншу точку відтворення, якщо така є.

    3 Відновлення образу. Звичайно ж, спочатку потрібно скопіювати всю оболонку. Образ системи – архів розділу, у якому було встановлено Windows. При цьому відбувається повернення всіх файлів користувача, які в момент створення зберігалися на диску.

    4 Засіб діагностики пам'яті – інструмент, який перевіряє відповідні розділи на комп'ютері.

    5 Командний рядок. Досвідчені користувачі можуть за допомогою цього інструмента усунути неполадки.


збільшити

Запуск програми з командного рядка( )

Відновлення за допомогою Acronis True Image( )

Крім стандартних рішень Windows, також є інструменти від сторонніх розробників. Найпопулярнішим вважається програма Acronis True Image.

Щоб повернути працездатність ОС, потрібно:

    1 Запустити програму.

    2 Вибрати "".


    збільшити


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

Хороша новина — відновити дані все-таки можна, погана доведеться витратити час і нерви, якщо немає бажання витрачати гроші і звертатися до фахівця. Складність відновлення файлів залежить від того, де саме вони знаходилися – у пам'яті телефону або на карті SD. Спробуємо розібратися, як відновити дані на "Андроїді" у різний спосіб.

Підготовка

Стерти потрібні файли можна будь-яким випадковим чином, наприклад, якщо не подумавши, скинути на заводські установки або видалити не ті файли з менеджера. Ще один варіант – перепрошивка гаджета.

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

Якщо очистилася картка SD

Отже, якщо втрата даних відбулася з флеш-карти, повернути втрачене не складе великих зусиль. Все, що вам знадобиться, - це наявність комп'ютера і, власне, картка SD.

Перше, що потрібно зробити, — завантажити спеціальну програму, яких на просторах інтернету безліч. Але краще, якщо це буде безкоштовна утиліта, наприклад, Recuva або TestDisk.

Залишилося лише вставити картку пам'яті в комп'ютер і відсканувати її через встановлену програму. Якщо все зроблено правильно, дані мають відновитись. Не забудьте зберегти врятовані файли після того, як відновити дані на "Андроїді" вдалося.

Чи є життя після hard reset?

Часто користувачі, не знайшовши іншого виходу, скидають телефон на заводські установки. У цьому випадку SD-карта залишається недоторканою, тобто всі файли на карті пам'яті зберігаються, а ось пам'ять телефону стирається начисто.

Для тих, хто задається питанням про те, як відновити скидання даних на "Андроїді" після hard reset, відповідь проста: допоможуть ті самі сторонні утиліти. Проблема в тому, що програма відновлення файлів може не підтримувати конкретну модель телефону. Тому має сенс спершу спробувати безкоштовну версію. Список програм, здатних відновити видалені дані на "Андроїді" - як на телефоні, так і на планшеті:

  • EaseUS MobiSaver;
  • iSkySoft Android Data Recovery;
  • Wondershare Dr.Fone;
  • Recovery;
  • 7-Data recovery.

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

Як отримати дані пам'яті телефону за допомогою комп'ютера?

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

  1. Клієнт завантажує необхідну утиліту на свій комп'ютер та встановлює її.
  2. Смартфон або планшет підключається до ПК за допомогою кабелю USB.
  3. Здійснити глибоке сканування даних.

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

Що таке бекап?

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

Спершу слід вимкнути телефон і далі одночасно натискати на кнопки включення та звуку. У вікні інженерного меню, що відкрилося, потрібно натиснути на вкладку backup and restore і далі - бекап. Скопійовані дані телефону будуть збережені в пам'яті флеш-карти і можуть бути перенесені на ПК у будь-який момент.

Тепер, коли ви в черговий раз поставите питання про те, як відновити дані з "Андроїда" після випадкового очищення, достатньо скористатися вкладкою restore в тому ж меню.

Хай живуть послуги «Гугл»!

Зазвичай усі гаджети, чи то телефон чи планшет, на базі "Андроїда" синхронізуються з акаунтом "Гугл". Якщо на апараті був виконаний вхід з облікового запису Google, а в налаштуваннях увімкнена синхронізація, відновити "Андроїд" без втрати даних не важко.

Якщо користувач раніше увімкнув синхронізацію, все, що потрібно зробити, — увійти до програми «Гугл Плей», використовуючи свої логін та пароль. Далі автоматично буде завантажено наступне:

  • усі контактні дані (адреси, номери телефонів, імена);
  • дані додатків;
  • фото та відео, збережені на "Гугл Диску".

У випадках коли немає облікового запису «Гугл» або не було здійснено синхронізацію, на жаль, відновити дані на "Андроїді" за допомогою бекапу не вийде.

Як повернути раніше встановлені програми

Якщо ви з будь-якої причини видалили мобільні програми, які тепер хочете повернути назад, робити це дуже просто. Для початку потрібно зайти в Google Play за допомогою свого облікового запису. У верхньому лівому куті можна побачити три горизонтальні лінії, при натисканні на які відкривається особистий розділ. Далі необхідно вибрати вкладку «Мої програми та ігри». У списку виберіть ті програми, які цікавлять, і встановіть їх повторно на свій смартфон.

Якщо ви хочете повернути платну програму, яку вже сплатили, достатньо просто перевстановити її. Як завжди, такі програми прив'язуються до облікового запису «Гугл» і не вимагають повторної оплати. Якщо у списку немає програми, яка вам потрібна, цілком можливо, що ви здійснили вхід під іншим обліковим записом. Інша причина відсутності програми - повне його видалення з магазину для всіх користувачів.

GT Recovery for Android: якщо немає комп'ютера під рукою

Припустимо, користувача облікового запису Google немає і комп'ютера теж. Що тоді робити? Як відновити дані на телефоні з "Андроїдом"? Навіть у цьому випадку є вихід, щоправда, доведеться дещо довше повозитися. Тут головне – наявність гарного мобільного інтернету та величезного терпіння.

Вирішити таку нелегку проблему можна за допомогою GT Recovery for Android. Цю програму можна знайти в Google Play. На момент написання статті програма надається безкоштовно і, за численними позитивними відгуками, є однією з найкращих у своєму роді. Єдиною негативною стороною цієї програми вважатимуться те, що потрібні root-права.

Спочатку потрібно завантажити та встановити програму на свій смартфон або планшет. Далі у вікні вказати, які саме програми необхідно знайти і відновити, і почати сканування.

На цьому етапі наберіться терпіння, процес сканування може тривати до 30 хвилин, залежно від обсягу телефону. Після завершення сканування на екрані з'явиться список усіх знайдених файлів. Виберіть потрібні та натисніть Next.

Залишилося лише вказати шлях для збереження. Врахуйте, що контакти будуть збережені у форматі vcf, тому доведеться зайти в адресну книгу та імпортувати їх туди із внутрішньої пам'яті.

Заходи профілактики

Після того як відновити дані програми на "Андроїді" вдалося, саме час подумати, як не наступити на ті самі граблі повторно. Ми вже писали про те, що таке бекап і для чого він потрібний. Не забудьте зайвий раз бекапити всі важливі файли, в майбутньому ця звичка допоможе заощадити час і гроші.

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

Висновок

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

Тут головне - заспокоїтись і постаратися не засмічувати пам'ять новими файлами, інакше відновлення втрачених даних буде проблематичним. Якщо початкового бекапу не було, а сторонні програми не допомогли самостійно впоратися з проблемою, доведеться звернутися до сервісного центру за більш кваліфікованою допомогою.

Користувачі зберігають на Айфонах величезну кількість інформації, втрата якої є вкрай небажаною. Тому резервне копіювання – це операція, яка має стати звичкою. Знаючи, як відновити iPhone з резервної копії, можна швидко повернути втрачені дані, незалежно від того, що спричинило їх видалення. Розберемо два способи повернення даних, щоб ви розуміли, який метод вам буде зручніше застосовувати.

Способи відновлення

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

  • Через iTunes.
  • Через сховище iCloud.

Вибір методу залежить від того, як було зроблено бекап інформації. Якщо ви зберегли копію через Айклауд, то повертати дані на Айфон потрібно з хмарного сховища; зробили копію на комп'ютері – доведеться підключити смартфон до ПК та синхронізувати пристрої.

Відновлення в iTunes

Якщо ви підключаєте Айфон до комп'ютера, то напевно у вас встановлена ​​програма iTunes, яка надає, серед інших функцій, можливість зберігати резервні копії та здійснювати повернення інформації з бекап-файлу. Копії в Айтюнс створюються автоматично, але ви можете зберегти дані вручну, якщо така необхідність з'явиться.

Підключіть iPhone до ПК та зайдіть у iTunes. Перейдіть на головну сторінку пристрою та перевірте розділ "Резервні копії". Знайдіть параметр «Автоматичне створення копій» – якщо вибрано «Цей комп'ютер», можна відновити інформацію з жорсткого диска через iTunes. Якщо вибрано значення iCloud, то повертати дані доведеться з хмарного сховища - про це детально розказано нижче.

Розглянемо порядок відновлення інформації з копії, що зберігалася на твердому диску. Телефон вже підключено до ПК. Що робити далі:


Дочекайтеся, доки інформація скопіюється на пам'ять Айфона. Після завершення відновлення потрібно знову налаштувати геолокацію, iCloud та інші сервіси Apple. Інформація без втрат повернута на телефон, можете далі користуватися ним.

Головне не забувати робити резервні копії, тоді жодних складнощів як втрати важливих повідомлень та контактів не виникне.

Відновлення через iCloud

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

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

Якщо було увімкнено створення бекапів у налаштуваннях iCloud, пристрій повинен був автоматично копіювати інформацію на хмарне сховище. Однак для надсилання даних до iCloud потрібно дотримання кількох умов:

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

Під час активації (мова, регіон, підключення до бездротової мережі) виберіть режим «Відновити з iCloud». Для авторизації в iCloud напишіть пароль Apple ID.

Потім потрібно ухвалити ліцензійну угоду, а також придумати пароль блокування та заново налаштувати сканер Touch ID. Запит на створення пароля блокування з'явиться лише в тому випадку, якщо ця функція була активною на пристрої до скидання налаштувань та видалення контенту.