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



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

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

Дрібниця перша. Моніторинг

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

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

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

Дрібниця друга. Пропущені повідомлення

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

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

Канали зв'язку в сучасному світі можуть бути різними. Це e-mail, SNMP, SMSS та інші. Все це дозволяє отримувати повідомлення і швидко реагувати на них. Найкраще впровадити в своїй компанії систему відправки повідомлень в режимі реального часу. У цьому випадку можна бачити все і відразу, а не отримувати повідомлення через хвилини, години чи дні після аварії, що трапилася або збою.

Дрібниця 3. Командний рядок допомагає не завжди

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

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



Дрібниця 4. Звітність та планування

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

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

Неправильне налаштування

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




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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.