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

Ось що слід контролювати:

• Цільовий час відновлення (RTO): Як довго системи можуть залишатися несправними, перш ніж це вплине на бізнес?
• Мета точки відновлення (RPO): Який обсяг втрати даних є прийнятним?
• Коефіцієнт успішного резервного копіювання: Чи завершується резервне копіювання за планом?
• Швидкість передачі даних: Як швидко можуть переміщуватися дані під час резервного копіювання?
• Використання сховища: Ваш обсяг пам'яті наближається до межі?
• Перевірки цілісності даних: Чи ваші резервні дані точні та не пошкоджені?
• Час реагування на інцидент: Як швидко можна усунути несправності?
• Кількість захищених ресурсів: Чи всі критично важливі системи охоплені?
• Споживання місця у сховищі резервних копій: Чи ефективно ви керуєте витратами на зберігання?
• Журнали доступу та журнали аудиту: Хто і коли мав доступ до ваших резервних копій?

Відстеження цих показників допомагає запобігти простоям, втраті даних та перевитратам коштів. Крім того, це гарантує, що ваша система резервного копіювання відповідає потребам бізнесу та вимогам дотримання нормативних вимог.

Запитайте експерта Демонстраційна сесія: Майстер-клас з моніторингу резервного копіювання гібридної хмари Veeam ONE | Вебінар

1. Цільовий час відновлення (RTO)

Цільовий час відновлення (RTO) – це визначення того, як довго ваші системи можуть бути недоступними після збою, перш ніж це почне шкодити вашому бізнесу. Простими словами, це максимальний час простою, який ви можете собі дозволити, перш ніж все знову має бути повністю функціональним. Карі Рівас, старший менеджер з маркетингу продуктів у Backblaze, пояснює це так:

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

Правильний підхід до відновлення (RTO) є критично важливим, оскільки він безпосередньо пов'язує ваші плани технічного відновлення з пріоритетами вашого бізнесу.

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

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

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

2. Цільова точка відновлення (RPO)

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

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

Ось вражаюча статистика: понад 72% компаній не досягають своїх цілей відновлення[1]. Часто це трапляється тому, що рішення щодо RPO розглядаються як суто технічні, а не стратегічні бізнес-рішення. Карі Рівас, старший менеджер з маркетингу продуктів у Backblaze, підкреслює це:

"Рішення про те, якого стандарту дотримуватися, є спільною відповідальністю. І ці стандарти… є цілями, яких повинні досягти команди ІТ-фахівців та постачальників інфраструктури"."

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

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

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

3. Коефіцієнт успішного резервного копіювання

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

Підтримка високого рівня успішності резервного копіювання є надзвичайно важливою – зрештою, неможливо відновити дані, які ніколи не резервувалися. У багатохмарних системах відстеження цього показника може бути складним через необхідність консолідації даних від різних постачальників. Наприклад, AWS Backup оновлює CloudWatch кожні 5 хвилин, вказуючи кількість завдань, тоді як Google Cloud оновлює свої показники резервного копіювання щогодини. Поєднання цих оновлень дає чіткіше уявлення про загальну продуктивність резервного копіювання.

До збоїв резервного копіювання може призвести кілька факторів. До них належать конфлікти планування з вікнами обслуговування (наприклад, для Amazon FSx або служб баз даних), нестача місця для зберігання або проблеми з мережею, що спричиняють переривання передачі даних між хмарні провайдери. Щоб уникнути цих проблем, налаштуйте автоматичні сповіщення, коли кількість збоїв перевищує п’ять завдань протягом години. Створення звітів про тенденції протягом 30 днів або більше може допомогти виявити повторювані проблеми, а не поодинокі.

Якщо збої не зникають, подумайте про налаштування свого підходу. Перехід на інкрементальні резервні копії безстрокового зберігання або безперервний захист даних (CDP) може зменшити обсяг переданих даних, зменшуючи навантаження на вашу систему. Майте на увазі, що AWS позначає завдання як "ТЕРМІН ДІЇ ВИЙШОВ", якщо вони не запускаються в заплановані терміни, що впливає на рівень успішності, навіть якщо не виникає технічних помилок. Регулярний перегляд і коригування розкладів резервного копіювання може допомогти запобігти конфліктам ресурсів у години пік. Точне налаштування цих процесів гарантує надійність ваших резервних копій, одночасно контролюючи інші критичні показники.

4. Швидкість передачі даних

Швидкість передачі даних визначає, як швидко дані резервного копіювання переміщуються з однієї точки до іншої, що безпосередньо впливає на час створення резервних копій. пропускна здатність стосується загальної ємності вашого мережевого з’єднання, пропускна здатність вимірює фактичну швидкість завантаження або вивантаження даних. Як стверджує Карі Рівас, старший менеджер з маркетингу продуктів у Backblaze:

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

Коли пропускна здатність падає, це може порушити графіки резервного копіювання та знизити продуктивність системи. Низька швидкість передачі даних означає, що резервне копіювання займає більше часу, що потенційно може перерости у робочий час. Саме тому концепція вікно резервного копіювання стає критично важливим – певний часовий проміжок, зарезервований для резервного копіювання, який не перешкоджатиме щоденним операціям. Якщо ваша пропускна здатність не може впоратися з навантаженням даних протягом цього вікна, у вас проблеми. В. Кертіс Престон, дописувач Network World, виділяє ризики:

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

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

Покращення швидкості передачі даних часто вимагає точного налаштування ваших налаштувань. Багатопотоковість – це один із способів підвищити продуктивність, передаючи кілька потоків даних одночасно, що дозволяє краще використовувати доступну пропускну здатність. Налаштування розмірів блоків або частин також може допомогти; більші частини зменшують накладні витрати, спричинені частими викликами API, хоча вони й потребують більше пам’яті. Для організацій, які борються з обмеженими вікнами резервного копіювання, перехід на інкрементальні резервні копії назавжди або безперервний захист даних (CDP) може стати домінантним. Ці методи мінімізують обсяг переданих даних, зменшуючи навантаження на вашу мережу.

5. Використання сховища

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

Гарний спосіб оцінити ефективність дедуплікації та стиснення – це порівняння Віртуальний розмір до Збережені байти. Якщо ці цифри майже однакові, це може свідчити про те, що дедуплікація працює не так ефективно, як мала б. Такі інструменти, як AWS Backup, надають оновлені показники сховища в CloudWatch кожні п’ять хвилин, тоді як Google Cloud оновлює дані сховища резервних копій щогодини, забезпечуючи вам часті оновлення стану вашого сховища.

Невидалення прострочених точок відновлення може призвести до непотрібних витрат. Як пояснює В. Кертіс Престон, відомий спеціаліст із резервного копіювання та відновлення:

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

Моніторинг зростання обсягу сховища як на рівні програм, так і на рівні хоста може виявити, які ресурси призводять до зростання витрат. Наприклад, ви можете виявити, що одна база даних монополізує резервне сховище, тоді як інші програми майже не зазнають змін. Ця детальна аналітика допомагає вам зосередити зусилля з оптимізації там, де вони найважливіші. Встановлення порогових значень – зазвичай приблизно на рівні 80% – також може дати вам достатньо часу для реагування, перш ніж буде досягнуто критичних рівнів.

Зрештою, розуміння показників виставлення рахунків, специфічних для кожного постачальника, є критично важливим, щоб уникнути несподіванок. Наприклад, AWS Neptune Загальний обсяг сховища резервних копій, що виставлено на рахунок Метрика включає як безперервне сховище, так і сховище знімків, з щоденною безкоштовною квотою, тоді як Google Cloud дозволяє фільтрувати показники за типом ресурсу. Знання цих деталей гарантує, що ви використовуєте правильні рівні сховища та контролюєте свої витрати.

6. Перевірки цілісності даних

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

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

Сучасні хмарні платформи пропонують інструменти, що допомагають контролювати цілісність даних майже в режимі реального часу. Наприклад, Резервне копіювання AWS оновлює показники в CloudWatch кожні п'ять хвилин, що дозволяє швидко виявляти та вирішувати потенційні проблеми. Деякі платформи навіть розрізняють статуси, такі як "Завершено" та "Завершено з проблемами", сигналізуючи про необхідність ретельнішої перевірки. З іншого боку, Сховище об'єктів інфраструктури Oracle Cloud застосовує проактивний підхід, автоматично відновлюючи пошкоджені дані за допомогою резервування. Для справжньої перевірки моніторингу цілісності вкрай важливо проводити фактичні тести відновлення.

Заплановані тести відновлення також допомагають виміряти Реальність часу відновлення (RTR) і Реальність точки відновлення (RPR) – ключові показники того, наскільки добре ваша система резервного копіювання працює порівняно з вашими цілями відновлення. Ці тести надають уявлення про реальну ефективність вашої стратегії резервного копіювання.

Для додаткового захисту, впровадження незмінне зберігання використання технологій Write-Once-Read-Many (WORM), таких як Блокування об'єктів Amazon S3, може запобігти зміні даних після їх запису. Це особливо цінно для захисту від атак програм-вимагачів. Однак важливо сканувати дані на наявність шкідливого програмного забезпечення або пошкоджень перед їх блокуванням, щоб уникнути постійного збереження помилок. Відстеження Оцінка якості даних, яка об’єднує такі показники, як узгодженість, повнота та точність, також може запропонувати чіткий знімок загального стану даних резервного копіювання в усіх хмарних середовищах.

sbb-itb-59e1987

7. Час реагування на інцидент

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

"Коли початкове завдання резервного копіювання завершується невдачею, існує висока ймовірність того, що інші наступні завдання також завершаться невдачею. У такому випадку ви можете найкраще зрозуміти перебіг подій за допомогою моніторингу та сповіщень". – Приписні вказівки AWS

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

• P1 (Критичний)Підтвердження протягом 5 хвилин, відновлення протягом 4 годин
• P2 (Високий)Підтвердження протягом 15 хвилин, відновлення протягом 12 годин
• P3 (Середній)Підтвердження протягом 1 години, відновлення протягом 24 годин

Надійні системи сповіщень є основою ефективного реагування на інциденти. Інтегруючи моніторинг резервного копіювання з такими інструментами, як Amazon CloudWatch або Google Cloud Monitoring, ви можете налаштувати сповіщення в режимі реального часу через такі сервіси, як Amazon SNS. Наприклад, налаштуйте тривоги для запуску запиту з високим пріоритетом, якщо протягом години не вдасться виконати більше п’яти завдань резервного копіювання.

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

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

8. Кількість захищених ресурсів

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

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

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

Налаштування сповіщень може ще більше покращити ваш контроль. Наприклад, ви можете налаштувати CloudWatch або Google Cloud Monitoring для надсилання сповіщень, якщо відсоток захищених активів падає нижче певного порогового значення, такого як 95% від загального обсягу ваших запасів. Такий проактивний підхід допомагає виявляти потенційні вразливості, перш ніж вони призведуть до втрати даних. Крім того, позначення ресурсів такими мітками, як "BackupTier: Gold" або "BackupTier: Silver", може оптимізувати дотримання політик та спростити відстеження між різними командами чи відділами.

Централізовані панелі інструментів – ще один важливий інструмент для забезпечення прозорості в багатохмарних середовищах. Наприклад, AWS Backup оновлює показники в CloudWatch кожні 5 хвилин, тоді як Google Cloud надає щогодинні оновлення щодо використання сховища. Використовуючи платформи, які нормалізують формати даних, такі як ті, що обробляють JSON або syslog, ви можете забезпечити узгоджену звітність для різних постачальників хмарних послуг. Регулярні аудити API інфраструктури додатково перевіряють, чи охоплено всі ресурси, допомагаючи вам підтримувати відповідність вимогам та уникати прогалин у захисті.

9. Використання місця для зберігання резервних копій сховища

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

Ще один важливий показник – використання пулу сховищ, який показує відсоток використаного простору порівняно з доступним у вашій системі резервного копіювання. Якщо використання починає наближатися до попередньо визначених порогових значень, час або розширити ємність, або видалити застарілі резервні копії. Наприклад, AWS Backup оновлює ці показники кожні 5 хвилин за допомогою CloudWatch, тоді як Google Cloud оновлює значення щогодини та повторює останні дані кожні 5 хвилин.

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

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

Щоб залишатися попереду, налаштуйте порогові оповіщення для проактивного управління. Ваша система моніторингу повинна повідомляти вас, коли використання сховища перевищує встановлені ліміти або коли кількість точок відновлення, термін дії яких минув, починає зростати. Також корисно сегментувати показники споживання за типом ресурсу, наприклад, екземпляри Compute Engine, бази даних SQL або системи Oracle. Таким чином, ви можете точно визначити, які робочі навантаження стимулюють зростання сховища, і відповідно налаштувати політики зберігання.

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

10. Журнали доступу та журнали аудиту

Кожна дія, пов’язана з вашою інфраструктурою резервного копіювання – чи то відновлення даних, зміна політики, чи навіть просто читання інформації – потребує ретельного запису. Журнали доступу та журнали аудиту надають детальний облік того, хто, до чого, коли та звідки мав доступ. Такий рівень прозорості є критично важливим як для розслідувань безпеки, так і для виконання нормативних вимог.

Журнали аудиту повинні фіксувати всі важливі деталі для кожної події. Це включає роль користувача або IAM, тип виконаної дії (наприклад, RestoreBackup, DeleteBackup, CreateBackupPlan), вихідну IP-адресу, ресурс, на який вплинула зміна, позначку часу та результат дії. Для тривалих процесів Google Cloud Backup and DR генерує два окремі записи в журналі: один на початку операції, а інший на її завершенні.

Хмарні платформи зазвичай поділяють журнали на дві категорії: Журнали активності адміністратора для змін конфігурації та Журнали доступу до даних для операцій, що стосуються конфіденційних даних. Журнали активності адміністратора зазвичай увімкнено за замовчуванням, але журнали доступу до даних часто потребують ручної активації. Наприклад, у Google Cloud журнали доступу до даних вимкнено за замовчуванням (за винятком BigQuery) через їх розмір. Однак увімкнення цих журналів має вирішальне значення для відстеження того, хто переглядає або відновлює конфіденційні дані, забезпечуючи дотримання правил конфіденційності.

Щоб посилити моніторинг, налаштуйте сповіщення в режимі реального часу для критичних дій, таких як DeleteBackup. Крім того, перенаправляйте журнали до централізованих сховищ, щоб відповідати вимогам щодо зберігання, які можуть коливатися від 30 днів до 10 років, залежно від стандартів відповідності. Централізовані варіанти зберігання включають такі платформи, як Azure Log Analytics або Cloud Storage.

Для багатохмарних середовищ такі інструменти, як Serionion може спростити керування журналами. Об’єднавши журнали з AWS CloudTrail, журналів активності Azure та журналів аудиту Google Cloud в єдину систему SIEM, ви можете досягти єдиної видимості всієї вашої інфраструктури резервного копіювання. Такий підхід не лише оптимізує моніторинг, але й розширює вашу здатність підтримувати відповідність вимогам на різних платформах.

Таблиця порівняння

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

Показники продуктивності зосередьтеся на тому, як швидко відбуваються резервні копії та відновлення. Вони відповідають на такі питання, як: Чи резервні копії завершуються вчасно? Чи можна достатньо швидко відновити дані під час кризи? Наприклад, якщо ваш цільовий час відновлення (RTO) встановлено на рівні 4 годин, але фактичний час відновлення (RTR) регулярно досягає 6 годин, це явна ознака того, що ваша система може потребувати капітального ремонту.

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

Метрики потужності допомагають уникнути збоїв, пов’язаних зі сховищем, шляхом моніторингу використання. Наприклад, налаштування сповіщень, коли використання сховища досягає 80–90%, може запобігти перебоям, спричиненим нестачею місця.

Категорія	Метрика	Призначення	Приклад вимірювання	Рекомендований поріг сповіщення
Продуктивність	Цільовий час відновлення (RTO)	Забезпечити відповідність швидкості відновлення потребам бізнесу	Хвилини або години для відновлення	RTR перевищує визначений бізнесом RTO
Продуктивність	Швидкість передачі даних (пропускна здатність)	Швидкість резервного копіювання та відновлення вимірювачів	МБ/с або ТБ/год	Нижче мінімальної швидкості обладнання
Продуктивність	Використання резервного вікна	Забезпечте завершення резервного копіювання у відведений час	Тривалість (ГГ:ХХ)	> 100% визначеного вікна
Безпека/Здоров'я	Коефіцієнт успішного резервного копіювання	Відстежуйте надійність захисту даних	Кількість успішних/невдалих операцій %	< 99% успіху або > 5 невдач на годину
Безпека/Здоров'я	Перевірки цілісності даних	Перевірте, чи дані не пошкоджені та чи їх можна відновити	Кількість успішних тестів	< 1 успішне відновлення за 24 години
Безпека/Здоров'я	Події стану здоров'я	Визначення постійних та тимчасових збоїв	Здорові, нездорові, деградовані стани	Будь-який статус "постійного нездорового здоров'я"
Ємність	Використання сховища	Запобігання вичерпанню сховища	% використаних / збережених байтів	> Місткість 80–90%
Ємність	Витрата місця для зберігання резервних копій сховища	Відстеження витрат на хмарне сховище та його використання	Великобританія або ТБ	Загальна кількість даних перевищує бюджетне порогове значення
Ємність	Кількість захищених ресурсів	Забезпечити охоплення всіх критично важливих активів	Кількість захищених екземплярів	Кількість < очікуваний запас

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

Висновок

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

Розглянуті нами показники зосереджені на трьох ключових областях: захист даних, безпеки, і контроль витрат. Встановлення порогових значень сповіщень та регулярне порівняння фактичного часу відновлення з вашими цільовими показниками RTO (цільовий час відновлення) та RPO (цільова точка відновлення) можуть допомогти вам виявити потенційні проблеми, перш ніж вони стануть критичними. Як влучно зазначає Коді Слінгерленд, сертифікований практикуючий спеціаліст FinOps:

"Не можна виправити те, чого не можна виміряти"."

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

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

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

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

поширені запитання

Які ключові показники слід відстежувати для успішного резервного копіювання в кількох хмарах?

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

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

Як компанії можуть збалансувати витрати та захист, встановлюючи цілі RTO та RPO?

Щоб знайти правильний баланс між вартістю та захистом під час налаштування Цільовий час відновлення (RTO) і Об’єктивна точка відновлення (RPO), Першим кроком є ретельний аналіз впливу на бізнес. Це допоможе вам визначити, які програми є абсолютно критичними та потребують найкоротшого часу відновлення (RTO) та періоду відновлення (RPO), а які можуть впоратися з довшим часом відновлення та деякими втратами даних. Наприклад, критичні робочі навантаження повинні мати часті резервні копії, тоді як менш важливі дані можна зберігати за допомогою більш економічних варіантів із довшими інтервалами резервного копіювання.

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

Serverion спрощує цей процес завдяки своїм рішенням для резервного копіювання в кількох хмарах. Незалежно від того, чи потрібне вам високопродуктивне SSD-сховище для критично важливих даних, чи бюджетне об'єктне сховище для архівування, їхні гнучкі опції дозволять вам досягти ваших цілей RTO та RPO, залишаючись у межах бюджету – і все це без шкоди для надійності та безперервності бізнесу.

Як я можу покращити швидкість передачі даних для резервного копіювання в кількох хмарах?

Щоб підвищити швидкість передачі даних у багатохмарних резервних копіях, зосередьтеся на кількох ключових методах. Почніть з використання паралельна обробка водночас зменшуючи обсяг даних, що передаються мережею. Налаштування кількох каналів резервного копіювання та ввімкнення середнього рівня стиснення можуть максимально використати вашу пропускну здатність, і все це без надмірного навантаження на ваш процесор. Ще одна порада? Розбийте великі файли на менші фрагменти – приблизно по 1 ГБ кожен – і призначте ці фрагменти окремим каналам. Це дозволяє кільком потокам даних працювати одночасно, значно покращуючи пропускну здатність.

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

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

Пов’язані публікації в блозі

• 5 найкращих практик резервного копіювання в гібридній хмарі
• Показники Cloud DR: пояснення RTO та RPO
• 5 найкращих показників продуктивності резервного копіювання для відстеження
• Повний посібник із моніторингу хмарних сховищ у реальному часі