Бекапи на Docker можна зібрати без важкого стеку, якщо потрібні локальні копії, офсайт через хмару і нормальне відновлення файлів. ZeroByte закриває саме цей сценарій: підключає джерела даних по SMB, NFS або WebDAV, складає снапшоти в локальний репозиторій і вміє писати в хмарне сховище через rclone. Нижче – практичний сценарій для homelab: контейнер на Docker, джерело з SMB-шари, локальний репозиторій на окремому диску і копія в Google Drive.
Тут є одна межа, яку краще не ігнорувати. ZeroByte ще не виглядає як інструмент, на який варто беззастережно складати єдину резервну стратегію. Для тестового або другорядного контуру підхід нормальний. Для єдиного джерела істини – ні. Тому логіка проста: запускати, перевіряти restore, але не викидати інші резервні копії.
Коли ZeroByte доречний, а коли вже ні
Цей стек доречний у домашній інфраструктурі, де дані лежать на NAS, Unraid або окремому файловому сервері, а резерви потрібно збирати на іншу машину. Сценарій особливо влучний, коли треба забрати каталог по SMB, скласти інкрементальні снапшоти локально і мати ще одну копію поза майданчиком.
Якщо ж потрібні складні політики, дедуплікація між великою кількістю вузлів, зрілий CLI-first workflow або жорсткі вимоги до надійності, межа настає швидко. У такому разі вже логічно дивитися в бік більш усталених backup-інструментів і не тримати критичний контур на ранньому продукті.
Як працює ZeroByte в цьому сценарії
Схема проста. Є volume – це джерело даних. Наприклад, SMB-шара з каталогу image library. Є repository – місце, куди складаються резервні копії. Репозиторій може бути локальним, S3-сумісним, SFTP, REST або rclone-бекендом. Далі створюється backup job: що копіювати, куди, коли запускати і скільки снапшотів тримати.
Практично це виглядає так: ZeroByte монтується в контейнері, доступається через веб-інтерфейс, підключає віддалену шару як джерело і створює снапшоти в локальному каталозі на окремому диску. Окремо додається rclone-конфіг, щоб той самий інтерфейс бачив хмарний бекенд. Для Google Drive це означає OAuth-конфіг у rclone і проброс цього конфіга в контейнер.
Офіційний сайт проєкту: 0byte.io. Там же є базова документація по контейнерному запуску та бекендах.
Покрокове налаштування ZeroByte: Docker, SMB, локальний репозиторій
1. Підготуйте каталог під контейнер
На хості створіть окрему директорію під compose-файл і дані. Локальний репозиторій краще виносити не на системний диск і точно не на маленький boot-носій. Інакше перший великий бекап закінчиться банальним заповненням файлової системи.
2. Запустіть контейнер
Сценарій нижче повторює робочу схему: веб-інтерфейс на окремому порту, доступ до FUSE і окреме монтування під репозиторій.
services:
zerobyte:
image: ghcr.io/0byte-app/0byte:latest
container_name: zerobyte
ports:
- "4096:4096"
cap_add:
- SYS_ADMIN
devices:
- /dev/fuse:/dev/fuse
privileged: true
environment:
- TZ=Europe/Kyiv
volumes:
- /etc/localtime:/etc/localtime:ro
- /srv/zerobyte/data:/data
- /srv/zerobyte/repositories:/repositories
restart: unless-stopped
Далі стандартно:
docker compose up -d
Після старту відкрийте веб-інтерфейс, створіть адміністратора і збережіть recovery key. Його потрібно прибрати в окреме надійне місце. Втрачати такий ключ без запасного шляху відновлення – погана ідея.
3. Додайте SMB-джерело
У розділі volumes створюється нове джерело типу SMB. Далі вказуються IP або ім’я сервера, назва шари та облікові дані. Перед збереженням обов’язково проганяється test connection. Це той етап, де найчастіше випливають банальні речі: неправильний share name, помилка в паролі, мережевий ACL або відсутній доступ у самого контейнера.
Під бекап краще брати не всю шару, а конкретний підкаталог. Так легше контролювати обсяг, вікно копіювання і реальну цінність даних. У практичному сценарії це зазвичай library, а не весь share цілком.
4. Створіть локальний репозиторій
У repositories виберіть local і вкажіть шлях не в стандартному каталозі контейнера, а на змонтованому диску. Ідея проста: резерви не повинні жити там само, де тимчасові дані застосунку. Якщо хост невеликий, різниця між цими двома шляхами закінчується дуже швидко.
Після створення репозиторію варто одразу переконатися, що він доступний і порожній, без старих снапшотів або конфліктів шляху.
5. Створіть backup job
Далі створюється job: вибір volume, вибір repository, розклад і retention policy. Для домашнього контуру зазвичай вистачає щоденного запуску і звичайної схеми на кшталт 7 денних, 4 тижневих і 6 місячних снапшотів. Це дає нормальний баланс між історією і зайнятим місцем.
Перший запуск робіть вручну. Так простіше відловити помилки на старті, не чекаючи ночі й мовчазного падіння за розкладом.
Як додати офсайт: Google Drive через rclone
Якщо потрібні бекапи на Docker з офсайтом, ZeroByte можна підв’язати до rclone. Сам застосунок бачить rclone як окремий тип репозиторію, але контейнеру потрібен доступ до готового конфіга.
1. Встановіть rclone на хості
rclone config
Далі створюється новий remote для Google Drive. Потрібно пройти OAuth-авторизацію, згенерувати client ID і secret у Google Cloud Console та завершити зв’язування акаунта. Якщо сервер без браузера, авторизацію зручно завершити на локальній машині, а токен перенести назад.
Тут часто ламаються дві речі. Перша – контейнер не бачить конфіг rclone. Друга – remote створений, але вказує не туди: не в той root, не в ту теку, або взагалі не має токена після OAuth.
2. Пробросьте конфіг rclone в контейнер
У compose додайте монтування файлу або каталогу конфігурації rclone. Конкретний шлях залежить від того, де конфіг лежить у вашому середовищі. Типова ідея одна: каталог з rclone.conf має бути видимим у контейнері.
volumes: - /home/user/.config/rclone:/root/.config/rclone:ro
Після зміни compose контейнер треба перезапустити:
docker compose down docker compose up -d
3. Створіть repository типу rclone
Після рестарту в інтерфейсі з’явиться rclone-бекенд. Далі обирається потрібний remote, наприклад Google Drive, і тека під резерви. Логіка проста: краще виділити окремий каталог тільки під ZeroByte, а не складати все в корінь диска.
Після створення нового репозиторію робиться окремий backup job для офсайту або ж використовується механіка mirror repositories, якщо вона підходить під ваш сценарій. Другий варіант прибирає дублювання job’ів, але спершу його все одно треба перевірити руками.
Де ZeroByte зазвичай ламається
Проблеми тут не екзотичні. Найчастіше все валиться на стику контейнера, файлової системи і зовнішніх бекендів.
- SMB-джерело підключається, але каталогів не видно. Зазвичай це права доступу або неправильний share/path.
- Локальний репозиторій створено на системному диску. Перший повний прохід з’їдає місце.
- rclone працює на хості, але не працює в ZeroByte. Майже завжди контейнер не бачить rclone.conf.
- OAuth для Google Drive завершився не повністю. Remote є, а доступу до каталогу немає.
- Перший бекап іде надто довго. Це не завжди помилка, а межа мережі, дисків або дрібних файлів у великій кількості.
- Є backup job, але немає перевірки restore. Така схема нічого не гарантує.
Окрема пастка – плутанина між копією, снапшотом і офсайтом. Локальний репозиторій на тому самому хості не замінює іншу платформу. Якщо машина або масив помре, локальний backup там і залишиться.
Як перевірити, що бекапи на Docker реально працюють
Справжня перевірка тут одна – restore. Не статус completed, не зелена іконка, не заповнений каталог у хмарі.
- Запустіть перший backup job вручну.
- Дочекайтесь завершення без помилок.
- Відкрийте snapshot і перевірте структуру файлів у browser.
- Виконайте restore одного файлу в custom location.
- Порівняйте вміст, розмір і читабельність відновленого файлу.
- Окремо повторіть restore з офсайт-репозиторію.
Якщо відновлення в custom location проходить, а файл відкривається без сюрпризів, базова механіка жива. Якщо перевірено тільки локальний репозиторій, а хмарний – ні, контур ще не верифікований.
Сповіщення і контроль виконання
У ZeroByte є окремий блок notifications. Для простого операційного контролю цього достатньо: webhook у Slack, Discord, Telegram або пошту. Практичний мінімум – отримувати успішне завершення і помилки. Повідомлення про старт зазвичай тільки шумлять, якщо job’ів багато.
Корисна звичка – не обмежуватись сповіщеннями. Раз на якийсь цикл треба відкривати snapshot, дивитися фактичний обсяг змін і робити тестове відновлення. Інакше легко жити з красивими алертами та мертвим backup-ланцюжком.
Коли краще взяти інший підхід
ZeroByte добре виглядає як легкий UI-шар для домашньої інфраструктури. Але якщо у вас кілька хостів, багато важливих даних і вимога до передбачуваного disaster recovery, такий стек стає компромісом. Там уже потрібні не просто бекапи на Docker, а зріліша схема: окремі політики, перевірений restore process, незалежний офсайт і інструмент, який давно відпрацював у продакшн-подібних умовах.
Для невеликого homelab це робочий варіант. Особливо якщо потрібен веб-інтерфейс, SMB-джерела і хмара через rclone без зайвого ручного клею. Але тримати його єдиним захистом критичних даних поки що рано. Спершу локальний репозиторій, потім офсайт, потім restore-перевірка. Все інше другорядне.