Авамар: Не вдається виконати резервне копіювання NDMP через помилку сегментації фатального сигналу 11 через використання томічної пам'яті

Індикація збою резервного копіювання

Такі симптоми спостерігаються, коли резервна копія Avamar NDMP стикається з помилкою сегментації (сигнал 11):

• Завдання резервного копіювання переривається з повідомленням про критичну помилку, подібним до такого:

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

• Записи в журналі показують незвично великі набори даних, що обробляються, наприклад:

avtar Info <8688>: Status 2017-10-13 19:32:37, 3,050,352 files, 2,419,299 directories, 5,119 GB (3,050,352 files, 1.913 GB, 41.42% new) 15049MB 60% CPU (1 open files)

• Повідомляється про високе споживання пам'яті, яке часто перевищує 15 ГБ оперативної пам'яті/SWAP для одного потоку резервного копіювання.
• Активні численні потоки NDMP (до 8 на клієнта), кожен з яких потенційно використовує 2 ГБ або більше пам'яті.
• Кілька великих резервних копій можуть виконуватися одночасно, що збільшує загальне навантаження на систему.
• Відповідний том містить мільйони файлів і каталогів (наприклад, 3 мільйони файлів у 2,4 мільйонах каталогів, що охоплюють 5,1 ТБ даних).
• Навіть якщо змінився лише невеликий обсяг даних (наприклад, 1,9 ГБ), процес резервного копіювання намагається надіслати кожен файл із NAS на обробку.

Основні фактори, що спровокували фатальний сигнал 11.

Сигнал 11 (помилка сегментації) генерується при зверненні процесу до пам'яті, яка йому не відведена. Під час резервного копіювання Avamar NDMP безпосередньо спричинили такі умови:

• Кілька великих резервних копій NDMP виконувалися одночасно.
• Одна резервна копія обробила 3 050 352 файли та 2 419 299 каталогів, що загалом становить 5,1 ТБ даних, тоді як лише 1,9 ГБ цих даних змінилися.
• Кожен потік NDMP може споживати ≥ 2 ГБ пам'яті. Клієнту було дозволено до 8 потоків, і кілька клієнтів були активні одночасно, що призвело до високого сукупного попиту на пам'ять.
• Процес резервного копіювання використовував приблизно 15 ГБ оперативної пам'яті/SWAP до збою.
• Avamar обмежує кількість потоків на клієнта, але НЕ накладає глобальне обмеження на загальну кількість потоків. Це дозволяє комбінованому використанню пам'яті перевищувати доступні ресурси.

Ці умови інтенсивного використання пам'яті призвели до того, що процес avtar зіткнувся з помилкою сегментації, записаною в журналі як:

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

Виправлення збоїв резервного копіювання Avamar NDMP, спричинених сигналом 11 (помилка сегментації)

Крок 1 - Оцініть поточне навантаження на резервне копіювання.

Використовуйте консоль Avamar Administrator або CLI для визначення томів, які генерують великі резервні копії NDMP.

Список активних завдань NDMP та використання їх ресурсів:

$ avtar -listjobs -type ndmp

 Крок 2 - Зменшіть одночасне резервне копіювання обсягу.

• Обмежте кількість томів, що створюються одночасно, щоб уникнути надмірного споживання оперативної пам'яті/SWAP.
• У адміністраторі Avamar відредагуйте розклад резервного копіювання та зніміть прапорець з вікон, що перекриваються.

Крок 3 - Розділіть великі обсяги на менші підобсяги

• Визначте обсяги з понад 3 мільйонами файлів або понад 5 ТБ даних (як у прикладі).
• Створюйте логічні підтоми на один рівень нижче в дереві каталогів.
• Налаштуйте кожен підтом як окремий клієнт NDMP в Avamar.
  •  Приклад: Створення нового клієнта NDMP для підкаталогу

$ avtar -addclient -name subvol1 -path /data/level2/subvol1

 Крок 4 - Налаштуйте параметри потоку NDMP.

• Збільште максимальну кількість потоків NDMP на клієнта, якщо NAS це підтримує.
• У конфігурації NAS NDMP збільште ліміт потоку зі стандартного 4 до 8, де це можливо.

Крок 5 - Обмежте кількість файлів на потік

• Під час створення політик резервного копіювання встановіть нижчий поріг "файлів на потік", щоб обсяг пам'яті кожного потоку становив менше 2 ГБ.
• Використовуйте Avamar Administrator → Policies → Advanced Settings , щоб налаштувати це значення.

Крок 6 – Контролюйте використання пам'яті під час резервного копіювання

• Слідкуйте за споживанням оперативної пам'яті та обміном на сервері Avamar під час виконання резервного копіювання.
• Переконайтеся, що обсяг доступної пам'яті значно нижчий за загальний обсяг доступної пам'яті (наприклад, менше 12 ГБ для завдання розміром 15 ГБ).
  • Моніторинг пам'яті в режимі реального часу

$ top -b -n 1 | grep avtar

 Крок 7 – Перевірте виправлення

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

$ tail -n 50 /var/log/avtar/backup.log