Borg Backup Infrastructure Report

01 — Текущо състояние

02 — Критични проблеми

03 — Скриптове и инструменти

Всички скриптове са в cyberpanel LXD контейнера на s12.

Текущ Cron (в cyberpanel контейнера)

Retention Policy (текуща)

04 — Архиви (52 бр.)

Локален repo: /var/backups/borg-home — от 17 септември 2025 до 24 февруари 2026

05 — Стратегия

Защо два repo-та?

Borg repo не може да се rsync-не и после да се prune-не различно на двете места. Ако rsync-неш с --delete и после prune-неш на s12, при следващия rsync старите архиви се трият и от s1. Без --delete пък се трупат orphan chunks и repo-то на s1 се разваля.

Затова: две отделни borg repo-та, всяко със своя retention. Бекъпът е един (прави се на s12), но се push-ва и към s1 като независим архив. Така на s12 можеш свободно да триеш стари архиви, а на s1 те си остават.

Преди / След

06 — Стъпки за изпълнение

1. Инсталиране на Borg на s1-backups

   Контейнерът е Ubuntu на Incus, стандартен apt install.

   ssh root@s1-backups apt update && apt install borgbackup -y borg --version

2. SSH ключ от s12/cyberpanel → s1-backups

   Cyberpanel контейнерът вече има ed25519 ключ. Копираме го към s1-backups.

   # От s12, вътре в cyberpanel контейнера: ssh-copy-id -i ~/.ssh/id_ed25519 root@s1-backups # Тест: ssh root@s1-backups hostname # трябва да каже: backups

3. Създаване на Borg repo на s1-backups

   Без криптиране — същото като локалния repo за лесен достъп.

   # На s1-backups: mkdir -p /backups/cyberpanel borg init --encryption=none /backups/cyberpanel/borg-home

4. Първоначален трансфер: push на всички текущи 52 архива към s1

   Вместо rsync, правим borg create от s12 към s1 repo-то. Но за първоначалния трансфер на всички 52 архива, rsync е по-бързо (после repo-то на s1 става самостоятелно и получава нови архиви чрез borg create).

   # Еднократно! От cyberpanel на s12: rsync -avz --progress \ -e "ssh -i /root/.ssh/id_ed25519" \ /var/backups/borg-home/ \ root@s1-backups:/backups/cyberpanel/borg-home/ # Проверка (от s1-backups): borg list /backups/cyberpanel/borg-home # трябва да покаже 52 архива

5. Нов скрипт: borg-push-to-s1.sh

   Веднъж дневно прави borg create от s12 директно в repo-то на s1 през SSH. Плюс щаден borg prune за s1 (пази много повече).

   #!/usr/bin/env bash — /root/scripts/backup/borg-push-to-s1.sh S1_REPO="ssh://root@s1-backups/backups/cyberpanel/borg-home" # 1. Създаване на архив в s1 repo borg create --verbose --stats --compression zstd,8 \ --exclude '**/node_modules/**' \ --exclude '**/.cache/**' \ --exclude '**/wp-content/cache/**' \ ... (същите excludes) \ "$S1_REPO"::cyberpanel-home-{now:%Y-%m-%d_%H-%M-%S} \ /home # 2. Prune на s1 (щаден — пази дълга история) borg prune -v --list "$S1_REPO" \ --keep-daily=30 \ --keep-weekly=52 \ --keep-monthly=12 # 3. Compact borg compact "$S1_REPO"

6. Промяна на prune на s12 — само последната седмица

   САМО след като стъпки 1-5 са завършени и проверени! Махаме --keep-weekly=52.

   # В borg-home-local.sh — променяме реда с prune: # Старо: borg prune -v --list "$BORG_REPO" --keep-within=2d --keep-daily=7 --keep-weekly=52 # Ново: borg prune -v --list "$BORG_REPO" --keep-within=2d --keep-daily=7

7. Обновяване на backup-manager.sh — unified restore

   Менюто показва архиви от двата repo-та. Избираш номер → системата знае от кой repo да restore-не.

   # backup-manager.sh добавя втори repo: LOCAL_REPO="/var/backups/borg-home" S1_REPO="ssh://root@s1-backups/backups/cyberpanel/borg-home" # List: показва от двата # Restore: по номер определя кой repo # WP DB restore работи идентично и в двата случая

8. Нов Cron

   Добавяме само един нов ред за ежедневния push към s1.

   0 */2 * * * /root/scripts/backup/wp-export-all-db.sh # DB export (2h) 10 */2 * * * /root/scripts/backup/borg-home-local.sh # Local borg (2h) 0 4 * * * /root/scripts/backup/borg-push-to-s1.sh # НОВ: Push to s1 (1/ден)

07 — Нов Cron график

08 — Как се възстановява

Ръчен restore (без менюто)