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