Авамар: Реплікація виконується на закритих клієнтах без байтів прогресу

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

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

• Клієнти нещодавно були виведені на вихідний код, але раніше репліковані на цільову версію. Оскільки ці клієнти проживають в іншому місці, окрім /RETIRED домену на цільовому домені потрібно виконати реплікацію 0 байт для зміни налаштувань облікового запису на цільовій системі. 
  • У цьому випадку реплікація 0 байт відбувається лише один раз, і наступні реплікації не відображають цих клієнтів у моніторі активності.
•  Резервні копії прострочені на джерелі, але зберігаються через "keep_last_backup" ЗАПУСК mcserver.xml.
  • Це налаштування дозволяє зберігати останню резервну копію для кожного клієнта навіть після закінчення терміну дії.
  • Якщо "keep_last_backup" встановлюється на джерелі, і прострочені резервні копії не існують на цілі, реплікація намагається відтворити ці резервні копії на ціль, але вони не реплікуються, оскільки вже закінчилися.
    • У цьому випадку реплікація на 0 байт відбувається щодня, доки не видаляються прострочені резервні копії на джерелі.
• Терміни дії були подовжені, наприклад, коли клієнти були виведені на пенсію на джерелі, з 60 днів до 1 року.
  • Операція «виведення клієнта на пенсію» дозволяє змінювати дату закінчення при виході з експлуатації клієнтів, але ці зміни не поширюються на резервні копії на цільовій системі.
  • Після завершення реплікації після виходу клієнтів на пенсію з новими термінами придатності, ці клієнти переходять на /RETIRED домену, але з тими ж датами закінчення, що й раніше.
    • Це означає, що резервні копії на цільовому пристрої закінчуються раніше, ніж ті, що на джерелі.
    • Коли це відбувається, реплікація намагається відтворити резервні копії, які були видалені з цілі.
    • Однак резервна копія залишається на цільовій копії до того, як сміттєзбірка (GC) видаляє її назавжди, і реплікація відновлює резервну копію на цільовій цілі, але з новою датою закінчення, яка відповідає джерелу.
      • Оскільки в цьому випадку немає чого реплікувати, відбувається реплікація на 0 байт.
        • Це може відбуватися щодня, оскільки резервні копії на цілі видалятимуться щодня для щоденних резервних копій.
        • Усі резервні копії на цілі зрештою видаляються і замінюються тими, що мають нові терміни придатності, які збігаються з тими, що на джерелі.
        • Коли всі резервні копії на цільовому пристрої стають такими ж, як на вихідному коді аж до термінів придатності, нульова реплікація більше не відбувається.

Ці записи можна ігнорувати, оскільки це очікувана поведінка.