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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Зміст
Введення
Попереднє планування
Щоденний огляд логів процесу резервного копіювання
Захист бази даних резервного копіювання або каталогу
Щоденне визначення тимчасового вікна резервного копіювання
Локалізація і збереження "зовнішніх" систем і томів
Максимально можлива централізація і автоматизація резервного копіювання
Створення та підтримка відкритих звітів, звітів про відкриті проблеми
Резервне копіювання повинно бути включено в процес контролю змін системи
Консультації з вендорами
Резервне копіювання
Різні дані - різні підходи до резервного копіювання
Операційна система
Прикладне програмне забезпечення
Програми для резервного копіювання: купити або розробити
Типи резервного копіювання
Повні копії
Додаткові копії
Різницеві копії
Резервний носій
Стрічка
Диск
Мережа
Зберігання резервних копій
Питання відновлення
Відновлення на "голому" комп'ютері
Перевірка копій

Введення

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

Попереднє планування

Резервне копіювання є стратегічним компонентом захисту даних (існує також дзеркалювання, снепшоти і реплікація даних). Але найважливішим, фундаментальним елементом всієї стратегії зберігання даних повинне стати планування резервного копіювання.
Всі компоненти інфраструктури резервного копіювання повинні враховуватися в процесі планування, а всі програми, сервери та тенденції збільшення ємності первинних сховищ даних не повинні залишатися без уваги. Дуже часто зміни в середовищі не приймаються до уваги. Це може викликати збої і зробити згубний вплив на роботу системи резервного копіювання.
Крім того, правильне планування дозволяє скласти більш повне уявлення про потреби і особливості роботи додатків з точки зору захисту даних. Програми баз даних, де присутні розділені "дзеркала" та програми, що працюють у файловій середовищі, в якій немає додаткового захисту даних, вимагають різних стратегій і підходів до резервного копіювання. Аналогічно, велике корпоративне додаток, розгорнуте на декількох серверах і передбачає складну взаємозалежність даних для забезпечення подальшого відновлення, буде вимагати відповідної синхронізації резервного копіювання.
Встановлення життєвого циклу і календаря операцій
Ефективна робота системи резервного копіювання вимагає щоденного успішного виконання визначених завдань. Однак є не менш важливі завдання, які виконуються щотижня, щомісяця, щокварталу і щорічно. Завдання з коротким циклом більшою мірою є тактичними, а завдання з великим циклом - стратегічними. У середовищі ефективного резервного копіювання всі завдання мають бути задокументовані і виконуватися згідно з розкладом.
Щоденні завдання є основою, з якої добре знайомі системні адміністратори. До них відносяться:
моніторинг завдань;
звіти про збої та успішне виконання;
аналіз і вирішення проблем;
маніпуляції зі стрічками і управління бібліотекою;
розклад виконання завдань.
У разі щотижневих, щомісячних та інших операцій треба звертати увагу на:
аналіз продуктивності;
тенденції зміни обсягів та планування цих змін;
розгляд та аналіз методики резервного копіювання;
перевірку можливості відновлення;
планування розвитку архітектури. Визначаємо щоденні, щотижневі та щомісячні завдання.
Документуємо їх, і переконуємося, що вони виконуються і генерують звіти в повній відповідності з розкладом. Всі ці тимчасові файли не можна випускати з уваги. Зберігатися вони будуть довго, пройде рік, завершиться річний цикл. Спочатку це здасться незручним, але потім з'явиться розуміння, як оптимізувати середовище (або виявиться, що середовище резервного копіювання вже оптимізована).

Щоденний огляд логів процесу резервного копіювання

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

Захист бази даних резервного копіювання або каталогу

Всі додатки резервного копіювання ведуть свою базу даних або каталог, необхідні для подальшого відновлення збережених даних. Втрата каталогу спричиняє втрату збережених даних. Хоча деякі додатки резервного копіювання мають механізми коректного читання стрічок та індексів для відновлення, це може бути непосильним завданням. Такий каталог повинен розглядатися як будь-яке інше критично важливий додаток баз даних. Бажано мати його дзеркальну копію або, принаймні, зберігати в RAID-системі. Крім того, бажано переконатися в тому, що каталог зберігається згідно з розкладом і без помилок.

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

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

Локалізація і збереження "зовнішніх" систем і томів

ПО резервного копіювання надає деякі звіти про щоденні сесіях резервного копіювання. Розглядати тільки їх і покладатися тільки на них ризиковано. ПО резервного копіювання генерує звіти лише про відомі йому сервери. Складні середовища часто мають "зовнішні" системи, системи, які беруть участь у роботі, але не включені в схему резервного копіювання. Це відбувається з різних причин. Куплена якимось підрозділом система і що опинилася поза полем зору IT-підрозділу деякий час може працювати з власним резервним копіюванням. Але рано чи пізно можливий збій, який призводить до втрати даних. Тоді фахівці IT-підрозділу отримують запит відновлення даних на системі, про яку їм нічого не відомо. Як правило, такі системи потрапляють в поле зору служби IT, занадто пізно. Вирішення цієї проблеми може виявитися важким і займе багато часу. Буде потрібно регулярний перегляд і мапування нової веб-адреси у вузли (ноди), фільтрація не пов'язаних із завданням адрес (додаткові мережеві карти, мережеві пристрої, принтери і т.д.), ідентифікація місця розташування і власників таких вузлів та внесення відповідних змін в політику резервного копіювання (в цьому випадку обсяги даних, що підлягають збереженню, збільшаться). Також важливо регулярне надання звітів власникам системи і додатків про те, що насправді зберігається, а що - ні.

Максимально можлива централізація і автоматизація резервного копіювання

Ключем до успішної захисту даних є їх цілісність. Але це не означає, що з усіма даними потрібен обходитися однаково. Навпаки - однаково треба звертатися з даними, подібними за обсягом і важливості для компанії. Проблема "зовнішніх" систем, про яку йшла мова трохи вище, якраз є прикладом порушення цілісності даних, що виникає через нецентралізованого управління резервним копіюванням. Нерідко операції резервного копіювання для Windows - і Unix-серверів відбуваються незалежно. Така організація могла передувати мережному зберігання. Крім того що це неефективно, подібна організація припускає різні набори процедур і різні стратегії резервного копіювання для різних платформ. Визначати цінність даних таким чином неправильно.
За географічним міркувань функції резервного копіювання можуть бути дійсно розподілені по віддаленим офісам, але, беручи до уваги якість сучасних комунікацій, вигода від такої децентралізації вельми невелика. У міру збільшення складності інфраструктури резервного копіювання для виконання повторюваних операцій бажано застосовувати засоби автоматизації.
Візьмемо, приміром, трудомістку задачу щоденного вивчення журналів (логів) виконання операцій. Автоматизація дозволить генерувати сигнали тривоги при появі в логах заздалегідь певних помилок. Вірно і зворотне: автоматизація допоможе накопичувати повторюються в логах помилки. Якщо в логах побачити одну помилку SCSI, це те ж саме, що побачити їх тисячу.
Перегляд всіх однакових помилок - заняття виснажливе, здатне відбити охоту до щоденного вивчення логів взагалі. Якщо правильно визначити виконувану завдання та очікуваний результат - засоби автоматизації, безсумнівно, зможуть позбавити від частини стомлюючої роботи.

Створення та підтримка відкритих звітів, звітів про відкриті проблеми

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

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

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

Консультації з вендорами

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

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

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

Різні дані - різні підходи до резервного копіювання

Погляньте на дані [1], які обробляються і зберігаються в типовій комп'ютерній системі. Зауважте, що деякі дані не змінюються практично ніколи, а інші постійно змінюються.
Частота зміни даних дуже важлива для розробки процедури резервного копіювання. Тому є дві причини:
Резервна копія - це не більше ніж знімок копійованих даних. Це відображення даних у певний момент часу.
І чим частіше змінюються дані, тим частіше варто виконувати їх резервне копіювання.
Системні адміністратори, добре розуміють, як працюють їхні комп'ютери, користувачі та програми, можуть швидко розподілити типи даних по різних категоріях. Але щоб вам було легше почати, нижче наведено кілька прикладів:

Операційна система

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

Прикладне програмне забезпечення

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

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

Щоб виконувати резервне копіювання, перш за все, потрібно мати відповідну програму. Ця програма повинна не тільки вміти робити прості копії даних на резервні носії, але і добре підходити для співробітників вашої організації та вимог бізнесу. Оцінюючи програми для резервного копіювання, слід звернути увагу на:
Можливості виконання резервного копіювання за розкладом
Управління розміщенням, циклами копій і використанням носіїв
Взаємодія з операторами (і / або автоматичними пристроями зміни носіїв), коли потрібно певний носій
Можливості, що полегшують пошук носія з певною копією заданого файлу.
Як ви могли помітити, це рішення для резервного копіювання має не тільки скидати біти і байти на резервний носій.
Прийшовши до цього, багато системні адміністратори розглядають одне з двох рішень:
Придбання комерційного рішення
Розробка своїми силами системи резервного копіювання з нуля (можливо, із застосуванням однієї або декількох технологій з відкритим кодом)
Кожен підхід має свої позитивні і негативні сторони. Враховуючи складність завдання, самостійно розроблене рішення, швидше за все, в чомусь буде поступатися комерційному (наприклад, в управлінні носіями, або не буде мати всеосяжної документації або технічної підтримки). Однак для деяких організацій це може бути не важливо.
Комерційне рішення, швидше за все, буде більш функціонально, але воно також може бути дуже універсальним і складним для поточних потреб організації. І все-таки, ця універсальність може дозволити вам залишатися з одним рішенням, навіть коли ваша організація зростає.
Як ви могли зрозуміти, чіткого підходу до вибору системи резервного копіювання немає. Можна лише порекомендувати вам врахувати при виборі наступні моменти:
Замінити систему резервного копіювання непросто, запровадивши її одного разу, ви будете використовувати її тривалий час. Хоча б тому, що у вас будуть архівні копії, які ви повинні мати можливість прочитати. Заміна системи резервного копіювання означає, що ви повинні або десь залишити початкову систему (щоб звертатися до архівних копій), або перетворити архівні копії у формат, сумісний з новою системою.
Залежно від обраної системи резервного копіювання, перетворення архівних копій може бути досить простим (хоча і тривалим) і полягати в обробці копій вже існуючої програмою, або дуже трудомістким і зажадати вивчення форматів копій і написання спеціальної програми.
Ця система повинна бути абсолютно надійною - вона повинна в точності копіювати все, що має, і тоді, коли повинна.
І коли прийде час відновлювати дані, будь то один файл або вся файлова система, система відновлення також повинна бути надійна на 100%.

Типи резервного копіювання

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

Повні копії

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

Додаткові копії

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

Різницеві копії

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

Резервний носій

Ми дуже акуратно використовували у попередніх розділах термін "резервний носій". І цьому є пояснення. Багато досвідчених системні адміністратори зазвичай мають на увазі під резервним копіюванням запис і читання стрічок, але сьогодні існують і інші варіанти.
Колись стримери (пристрої для читання / запису стрічок) були єдиними пристроями зі знімними носіями, придатними для виконання резервного копіювання. Однак, це положення змінилося. У наступних розділах ми розглянемо найбільш популярні резервні носії і оцінимо їх переваги та недоліки.

Стрічка

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

Диск

У минулому диски ніколи не використовувалися в якості резервного носія. Однак ціна зберігання на дисках впала до тієї позначки, коли в деяких випадках зберігання резервних копій на дисках має сенс.
Головною причиною для використання дисків в якості резервних носіїв може бути швидкість. Це найшвидші носії даних з існуючих. Швидкість може бути важлива, якщо у вашому центрі даних для резервного копіювання відводиться невелике вікно, а обсяг копійованих даних великий.
Але дисковий сховище - не ідеальний резервний носій з ряду причин:
Диски зазвичай не є знімними. Один з головних чинників ефективної стратегії резервного копіювання полягає в зберіганні резервних копій поза вашого центру даних, в якомусь віддаленому сховище. Резервна копія робочої бази даних, що зберігається на диску за півметра від самої бази даних - це не резервна, а просто копія. І такі копії будуть не дуже корисні, якщо ваш центр даних і всі, що в ньому знаходиться (включаючи ваші копії), буде пошкоджено або зруйновано при несприятливому збігу обставин.
Диски коштують дорого (принаймні, у порівнянні з іншими резервними носіями). Бувають ситуації, коли гроші насправді не грають ролі, але в будь-яких інших обставин витрачати гроші на диски для зберігання резервних копій - означати зберігати менше копій, якщо загальна вартість зберігання копій повинна бути низькою. Чим менше копій, тим менше надмірність, яка може бути корисна, якщо якась копія з якоїсь причини не прочитається.
Диски дуже вразливі до зовнішніх впливів. І навіть якщо ви витратите додаткові гроші на знімні жорсткі диски, їх уразливість може бути проблемою. Якщо ви упустите жорсткий диск, ви втратите свою резервну копію. Можна придбати спеціальні корпусу, які можуть скоротити (але не повністю виключити) цю загрозу, але це ще більше збільшить вартість і без того дорогого рішення.
Диски - це не архівний носій. І навіть якщо припустити, що ви змогли подолати всі інші проблеми, пов'язані з резервним копіюванням на диски, вам слід врахувати наступне. Багато організацій з юридичних вимогам повинні зберігати дані протягом певних періодів часу. Шансів прочитати дані з 20-річною стрічки набагато більше, ніж з 20-річного диска. Наприклад, виникає питання, чи буде у вас необхідне обладнання, щоб підключити старий диск до комп'ютера? Ще один момент, який слід врахувати - диск набагато складніше картриджа диска. І коли мотор 20-річної давності повинен буде розкрутити 20-річні дискові пластини і над ними повинні будуть "парити" 20-річні головки читання / запису, яка ймовірність, що все це буде справно працювати, пролежавши без руху 20 років?
Зауваження
Деякі центри даних роблять резервні копії на диски, а після завершення копіювання ці копії записують на касети з метою архівації. Це дозволяє максимально швидко завершити копіювання у відведеному для нього вікні. Запис резервних копій на стрічку може виконуватися пізніше, у будь-який інший час дня, головне, щоб запис на стрічку закінчилася до моменту, коли буде готова наступна копія.
Але незважаючи на все вищесказане, тим не менше, бувають ситуації, коли копіювання на диску може мати сенс. У наступному розділі ми дізнаємося, як такі диски можна поєднувати з мережевими технологіями для реалізації цілком життєздатного (хіба що дорогого) рішення резервного копіювання.

Мережа

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

Зберігання резервних копій

Коли резервні копії зроблені, що має відбутися далі? Очевидна відповідь на це питання - ці копії повинні бути збережені. Проте, зовсім не так очевидно, що саме слід зберігати - і де.
Щоб відповісти на ці питання, ми повинні спочатку врахувати обставини, при яких будуть використовуватися резервні копії. Можна виділити три основні ситуації:
Відновлення окремих файлів за запитом користувачів
Глобальне відновлення при надзвичайній ситуації
Архівне сховище швидше за все ніколи не буде потрібно
На жаль, між першою і другою ситуацією існують несумісні протиріччя. Коли користувач видаляє файл випадково, він хоче повернути його негайно. Отже, резервний носій має бути не далі кількох метрів від комп'ютера, на якому повинні бути відновлені дані.
У разі надзвичайних ситуацій необхідно буде виконати повне відновлення одного або декількох комп'ютерів у вашому центрі даних, а якщо сталася катастрофа буде мати фізичний характер, вона зруйнує не тільки ваші комп'ютери, але і всі резервні копії, що зберігаються поруч. Ви опинитеся в жахливому становищі.
Питання архівного сховища менш спірний - ймовірність того, що ви скористайтеся ним, досить мала, тому якщо резервний носій зберігається далеко від центру даних, це не повинно бути проблемою.
Для вирішення цих різних завдань можуть бути обрані різні підходи, в залежності від потреб організації. Перший можливий підхід полягає в зберіганні копій за кілька днів у себе на місці, а потім переносити ці копії в більш безпечне віддалене сховище, коли будуть створені нові щоденні копії.
Інший підхід полягає в підтримці двох наборів носіїв:
Набір носіїв в центрі даних, що використовується виключно для відновлення окремих даних за запитом
Набір носіїв для віддаленого зберігання і відновлення у випадку надзвичайних ситуацій
Звичайно, наявність двох наборів увазі необхідність робити всі резервні копії двічі або копіювати їх. Це можна зробити, але подвійне резервне копіювання може зайняти багато часу, а для копіювання резервних копій можуть знадобитися кілька пристроїв для роботи з резервними копіями (і можливо, виділити для копіювання окремий комп'ютер.
Складність для системного адміністратора полягає у дотриманні балансу між задоволенням потреб користувачів і наявністю резервних копій на випадок найгірших ситуацій.

Питання відновлення

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

Відновлення на "голому" комп'ютері

Вираженням "відновлення на голому комп'ютері" системні адміністратори описують процес відновлення повної копії системи на комп'ютері, на якому немає абсолютно ніяких даних - ні операційної системи, ні додатків, нічого.
Взагалі можна виділити два основних підходи до відновлення на голому комп'ютері:
Перевстановлення, за якою слідує відновлення
Тут базова операційна система встановлюється таким же чином, як і на абсолютно новий комп'ютер. Коли операційна система встановлена ​​і правильно налаштована, що залишилися диски можна підключити і відформатувати, і відновити всі копії з резервних носіїв.
Диски для відновлення системи
Диск для відновлення системи - це завантажувальний носій певного роду (зазвичай CD-ROM), який містить мінімальну системне оточення і дозволяє виконувати самі основні адміністративні задачі. Оточення відновлення містить необхідні утиліти для розбиття на розділи та форматування дисків, драйвери пристроїв, необхідні для звернення до пристрою з резервними копіями, і програми, необхідні для відновлення даних з резервних носіїв.
Зауваження
Деякі комп'ютери здатні створювати завантажувальні стрічки і завантажуватися з них, і таким чином, дозволяють почати процес відновлення. Однак, це підтримують далеко не всі комп'ютери. Наприклад, комп'ютери, засновані на архітектурі PC, не допускають такого підходу.

Перевірка копій

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

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
72.3кб. | скачати


Схожі роботи:
Копіювання переміщання та форматування абзаців Опис основних прийомів копіювання переміщання
Програми копіювання рядка
Захист програми від нелегального копіювання
Копіювання вмісту файлу 1 в інші файли
Робота із текстом Виділення копіювання форматування тексту у редакторі Word
© Усі права захищені
написати до нас