Кліффхангер: Резервні копії вірні… ось… так?

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

Але тоді, коли ви запитаєте резервну копію SPECIFIC, половину часу їх там немає:

• Диск переповнився
• Стрічка провалилася
• Схоже, хтось відключив завдання резервного копіювання
• Мережевий зв’язок мав час простою
• Ми замовили цей диск років тому, але фінанси не затвердили замовлення на купівлю
• Файли пошкоджені
• Файл містить неправильну базу даних
• Тільки резервне копіювання журналу транзакцій (марне без повного)

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

Але навіть після цієї майже катастрофи я не можу переконати сисадмінів покращити ситуацію. Тож мені цікаво, які поради щодо відкриття людям очей? Мені здається, ми йдемо по краю скелі.

Ви завжди повинні виправляти ці речі зверху.

Чи підкріплена чи зрозуміла менеджмент поточною стратегією резервного копіювання? Якщо ні, то марно.

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

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

З чого почати? Це катастрофа, яка чекає, що трапиться. Основна функція Sysadmins - забезпечити резервне копіювання та відновлення даних. Все інше є другорядним. Ні, якщо ні, але є.

Ось кілька дій, які ви можете зробити:

1. Відстежуйте показники рентабельності клієнтів для відновлення. Слід створити звіт, який показує, скільки запитів на відновлення було успішним. Все, що менше 100%, повинно бути ретельно досліджено. Управління любовних звітів, і це важкі докази.

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

3. Зверніться до менеджера системного адміністратора та висловіть свої занепокоєння. Будьте озброєні доказом того, що реставрації не працюють. Якщо жодної радості не піднімається вище.

Серйозно - штурхати. Такі речі можуть знищити компанію.

Запропонуйте (як мінімум) щорічні тести на відновлення після аварій. Робота, необхідна для успішного виконання тесту, повинна виявити недоліки.

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

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

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

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

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

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

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

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

Я несу відповідальність за близько 200 серверів, поширених на північному заході Великобританії, і це, очевидно, занадто багато, щоб перевірити вручну.

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

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

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

Деякі з серверів використовують Backup Exec, деякі NTBackup, а деякі просто копіюють свої файли на інший сервер по всій мережі. Не має значення, який тип резервного копіювання роблять сервери, оскільки легко налаштувати мій VBScript, щоб перевірити наявність помилок. Мій сценарій насправді досить базовий, він просто відкриває звіт про резервну копію у вигляді текстового файлу та наводить фрази на зразок "не вдалось встановити", "повну стрічку", "помилка CRC" тощо тощо. Я впевнений, що це зробив би професійний програміст витончена робота. Однак вся справа проста і надійна, і вона є ініціативною в тому сенсі, що я бачу звіт про помилку резервного копіювання, хочу я чи ні, і я не зміг помітити помилку, лише якщо свідомо вирішив ігнорувати звіт.

JR

PS 99% відмов резервного копіювання - це те, що користувачі забули змінити стрічку резервного копіювання. Ви не любите люсеров :-)

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