Рятування та відновлення серверів
Відновлення пошкоджених даних
Пошкодження приходять з боку дефектних дисків, втрати живлення, збоїв ядра та невдалих оновлень, і найчастіше виявляються як бази даних, що не запускаються, чи файли, що не читаються. Відновлення — це спершу знімок образу, потім ремонт копій (ніколи не оригіналів), витягування максимум корисних даних і заповнення решти з резервних копій.
Головне
- Припиніть записи одразу та зніміть образ постраждалого сховища до ремонту.
- Діагностуйте роздільно: апаратура, файлова система чи прикладний рівень.
- Чиніть копії інструментами fsck/xfs_repair і засобами баз даних, ніколи не оригінали.
- Спершу витягніть читані дані; агресивний ремонт здатен знищити відновлюваний вміст.
- Заповнюйте прогалини з найсвіжіших перевірених резервних копій.
- Замініть підозріле обладнання: пошкодження, що сталося один раз, зазвичай повторюється.
- Додайте моніторинг SMART і живлення через ДБЖ, щоб історія не повторилася.
- Далі впровадьте розклад перевірок файлової системи та верифікації копій.
Часті запитання
Чи можна врятувати пошкоджену базу MySQL?
Часто значною мірою: режими force-recovery в InnoDB плюс витягування по таблицях повертають більшість даних у типових випадках.
Чи є RAID резервною копією?
Ні: RAID переживає відмову диска, але не пошкодження, видалення чи шифрувальника; версіоновані копії все одно потрібні.
Як запобігти повторенню?
Моніторинг SMART, ДБЖ, ECC-пам'ять на критичних базових серверах і перевірені копії.
А якщо копій немає?
Форензик-витягування ми пробуємо, але результати бувають різними; саме тому ми наполягаємо спершу на копіях.
Допомога Kinetikatech: рятування та відновлення серверів
Ми бралися за це сотні разів: Аварійна реакція для зламаних, пошкоджених чи що відмовили серверів: ізоляція, діагностика, відновлення й посилення. Служба Видалення шкідливого ПЗ та Адміністрування серверів дає замкнений цикл: ми оцінюємо, впроваджуємо, цілодобово стежимо й підхоплюємо за 30 хвилин, коли це критично.