КРИПТА БЕЗ KYCОренда GPU · 3, 7 або 30 днів
Capordia
Мова: Українська
Меню
Безперервність / Відновлення

Резервна копія має давати змогу продовжити роботу.

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

01

Визначте стан, який потрібно відновити, перш ніж обирати файли

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

Для навчання PyTorch документація розрізняє параметри моделі та checkpoint для продовження, що містить зокрема стан оптимізатора. Визначте елементи, потрібні для вашого власного протоколу: прогрес, можливий планувальник, дані та інші стани застосунку. Експорт, призначений лише для інференсу, може бути придатним для цього використання, але недостатнім, щоб продовжити навчання з тієї самої точки.

02

Зробіть спробу незалежною від робочого каталогу

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

Використайте функцію відновлення вашого інструмента в цьому периметрі. Restic дає змогу, наприклад, вибрати призначення за допомогою --target і переглянути відновлення за допомогою --dry-run. Його документація попереджає, що відновлення на місці може залишити частковий стан, якщо його перервати. Ці можливості ілюструють метод; вони не означають, що Restic або керована резервна копія надаються разом з орендою Capordia.

03

Перевіряйте послідовно копію, стан і використання

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

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

Три рівні взаємодоповнювального контролю
РівеньПитанняЕлемент для збереження
ЦілісністьЧи отриманий пакет відповідає запланованому?Перелік і результат перевірки
Відновлений станЧи дають файли та залежності змогу завантажитися?Версії, шляхи та виявлені розбіжності
ВикористанняЧи дає репрезентативна операція очікуваний результат?Тестові вхідні дані, вихідні дані та рішення
04

Розв’язаний приклад: неушкоджений архів, який не відновлює роботу

Повністю вигаданий випадок: кампанія містить 240 справ. На збереженій точці 180 прийнято, а 60 залишається обробити. Команда відновлює архів в окремому просторі. Усі перелічені файли проходять перевірку цілісності, але застосунок не знаходить таблицю відповідності, яку досі завантажували з робочого місця колеги. У відновленні відмовлено: стан неможливо відновити автономно.

Команда додає точну версію цієї таблиці до пакета й документує її шлях. Вона повторює відновлення в новому призначенні та перевіряє реєстр: 180 + 60 = 240 ідентифікаторів, без дублікатів. На десяти пробних справах із шістдесяти решти обробка створює двадцять очікуваних файлів, тобто два на справу. Їхній вміст прийнято за встановленими критеріями. Ці десять проб залишаються окремо від результатів виробництва; початковий реєстр не просувається цим тренуванням.

05

Виміряти повну тривалість і знати, що вона доводить

Заміряйте час від початку необхідної підготовки до прийнятого результату, розрізняючи очікування, відновлення, налаштування та перевірку. У нашому вигаданому прикладі ці етапи тривають відповідно 15, 75, 20 і 25 хвилин: загалом 135 хвилин, тобто 2 год 15 хв. Для внутрішнього вікна у три години залишковий резерв становить 180 − 135 = 45 хвилин. Цей розрахунок не описує жодної продуктивності сервісу.

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

Вигаданий час для описаної проби
ЕтапЧас
Підготувати призначення15 хв
Відновити пакет75 хв
Налаштувати застосунок20 хв
Прийняти результат проби25 хв
Разом / резерв на 3 години135 хв / 45 хв
06

Завершити тренування та зберегти чітку наступну дію

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

Повторюйте пробу, коли змінюється формат резервної копії, програмне забезпечення або важлива залежність, а також перед строком, який ускладнив би відновлення. Частота залежить від проєкту; вона не є автоматичним зобов’язанням оренди. На період 3, 7 або 30 днів передбачте час, щоб перевірити відновлення та передати його результат людині, яка використовуватиме подальшу роботу.

Запитання для ухвалення рішення

Чи достатньо правильної контрольної суми, щоб прийняти резервну копію?

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

Чи потрібно відтворювати все виробництво для кожної проби?

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

Що робити, якщо проба успішна лише за доступного старого каталогу?

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

ПРОДОВЖИТИ СПРАВУПереглянути конфігураціїПереглянути часті запитання