FreeBSD: Home NAS, part 13: планування зберігання даних та бекапів
0 (0)

Автор |  28/02/2026
0 коментарів
Click to rate this post!
[Total: 0 Average: 0]

Коли тільки починав робити свій NAS і думав про бекапи, то все здавалось доволі простим: є робочий ноутбук з даними, є сервер з FreeBSD під NAS – треба просто взяти, і скопіювати дані.

Тому перша задумка була мати backup-скрипт/и на Linux-хостах, які б з rsync заливали дані на NAS, а потім з NAS іншим скриптом заливати дані до Rclone remotes.

Але…

Але коли почав вже робити, то виникло питання:

  • rsync з хоста setevoy-work заливає дані на NAS
  • в цей жеж час rsync з хоста setevoy-home заливає свої дані

А коли запускати rclone => Google Drive? Як знати, що всі дані з хостів вже готові для копіювання?

І це була тільки верхівка айсбергу задачі по організації процесу.

Всі частини серії по налаштуванню домашнього NAS на FreeBSD:

“Технічне завдання”: складність організації даних та бекапів

Отже, виявилось, що тут є купа нюансів:

  • хостів, з яких треба робити бекапи – не один, і не два, і навіть не три:
    • є робочий ноутбук з Arch Linux
    • є домашній ноутбук з Arch Linux
    • є ігровий ПК, на якому Windows для ігор і Arch Linux для роботи – бо раніше (до “сезону блекаутів”) це був мій робочий комп
    • є власне сервер з FreeBSD під NAS
    • нещодавно з’явився Raspberry Pi (див. Raspberry Pi: перший досвід і установка Raspberry Pi OS Lite)
    • а ще і телефон з власними даними типу фоток
  • на кожному хості є різні типи даних:
    • відносно статичні та однакові дані для ноутбуків/ПК – фото, відео, документи
    • часто змінюються, але в цілому однакові на ноутбуках/ПК, хоча можуть дещо відрізнятись – робочі дані по проектам, якісь власні скрипти
    • конфіденційні дані, але однакові на всіх хостах – SSH-ключі, бекапи KeePass/1Password, Recovery Codes тощо
    • колекція home video 😉
    • системні бекапи – різні конфіги з /etc, /usr/local/etc, ~/.ssh/config, всякі dotfiles налаштувань OpenBox або KDE Plasma
  • всі ці дані треба синхронізувати на декілька зовнішніх ресурсів (далі – просто “клауди”):
    • ZFS datasets на самому NAS
    • зберігати копії в клаудах – Google та/або Proton Drive, AWS S3 чи Backblaze
  • і до всього цього – мати резервні копії резервних копій на випадок випадкового видалення, для чого є:
    • ZFS snapshots – резервні копії на самому NAS
    • Syncthing Trash – резервні копії Syncthing
    • rclone --backup-dir – при копіюванні змін з NAS в клауди використовується окремий каталог для зберігання видалених або змінених даних
  • і все діло треба ще і автоматизувати, аби копіювання з NAS до Google Drive не виконувалось одночасно з копіюванням з хостів на NAS
    • тобто, просто запустити rsync з робочого ноута можна – але як знати, коли запускати rclone з NAS в Google Drive?

Відчуваєте, як в голові починається каша? 😉

Далі в цьому пості я всі remotes буду писати просто як “Google Drive” або “клауди” – але сюди ж входять і Proton Drive, і AWS S3, і, можливо, якісь інші, які почну використовувати пізніше – бо Rclone дає просто безліч варіантів (UPD: замість AWS S3 взяв собі Backblaze, див. Backblaze: знайомство з B2 Cloud Storage – перші враження).

Просто поки що Google Drive основний, хоча, можливо, я буду взагалі зав’язувати роботу з Google, бо їхній “AI”, який вони пхають в кожну дірку вже починає зайо*вати.

Схема моїх хостів та мереж

Для загальної картини схематично всі хости та мережі можна відобразити так:

В офісі знаходиться MikroTik RB4011, який грає таку собі роль “VPN-хаба” – на ньому налаштований WireGuard, який об’єднує офісну та домашню мережі і до якого підключений сервер в Digital Ocean, на якому зараз працює rtfm.co.ua.

Про MikroTik писав в пості MikroTik: перше знайомство та Getting Started, про WireGuard на ньому – MikroTik: налаштування WireGuard та підключення Linux peers, і там жеж є більш детальна схема мережі.

Отже, питання мережі вирішено – тепер треба з усіх цих хостів почати збирати дані і якось продумати організацію їхнього збереження на NAS та процес бекапу з хостів на NAS – і з NAS в клауди.

Типи та класи даних для зберігання і бекапів

Коли я почав планувати організацію збереження даних на NAS, то в мене сформувався такий підхід:

  • всі дані ділимо на класи
  • для кожного класу маємо окремий ZFS dataset  – маємо можливість налаштовувати власні квоти, окремі політики снапшотів та їхніх retention
  • кожен датасет має власний remote backend в Rclone – маємо можливість налаштувати власні параметри шифрування

Головний “source of truth” даних – це робочий ноутбук: тут 1 терабайт диск, тому на ньому зберігаються всі дані, які потім вже бекапляться на NAS з rsync, а частина даних синхронізується з домашнім ноутбуком та NAS через Syncthing.

Всі свої дані виділив в такі класи:

  • User Data: дані з /home/setevoy на ноутбуках на ПК:
    • Shared Static Unencrypted Data:
      • ці дані однакові на всіх хостах
      • сюди входять всякі ~/Books, ~/Music, ~/Photos
      • в Google зберігаються просто plaintext, аби можна було через Web щось подивитись або скачати без Rclone
      • синхронізуються між NAS, setevoy-work та setevoy-home з Syncthing (див. FreeBSD: Home NAS, part 12: синхронізація даних з Syncthing)
    • Shared Dynamic Unencrypted Data:
      • дані на всіх хоста – однакові або з невеликими відмінностями
      • часто оновлюються та/або можуть мати багато “мусору” типу каталогів .git
      • в Google Drive зберігаються просто plaintext
      • сюди входять всякі ~/Work, ~/Projects (власні скрипти), ~/Opt (MikroTik WinBox, якісь локальні Prometheus Exporters, etc)
      • для таких даних source of truth – робочий ноут, а на NAS – mirror даних з робочої машини з rsync під час виконання бекапів
      • на домашній комп, при потребі, просто синхронізувати вручну з NAS
    • Shared Static Crypted Data:
      • дані, однакові на всіх хостах
      • але конфіденційні, тому в Google Drive будуть шифруватись
      • сюди входять ~/Vault (Recovery Codes, KeePass/1Pass, etc)
      • синхронізуються/бекапляться на NAS з rsync з робочого ноута
    • Non-Shared Static Crypted Data:
      • колекція приватних відео – зберігається тільки на робочому ( 🙂 ) ноуті та на самому NAS
      • в Google Drive будуть шифруватись і імена каталогів, і імена файлів, і самі дані
      • сюди входить ~/Films/Private/
      • синхронізуються/бекапляться на NAS з rsync з робочого ноута
  • System Data: різні dotfiles, конфіги з /etc, бекапи сервісів та блогів:
    • System Backups:
      • /boot, /etc, /usr/local/etc, ~/.ssh/config, /root, etc – з усіх хостів на NAS
      • різні конфіги і скрипти з самого FreeBSD
    • Services Backups:
      • тут в основному локальні дані самого NAS, на якому в мене WordPress з моїм приватним щоденником, VictoriaMetrics з метриками всіх хостів і моїм Self-Monitoring (див. InfluxDB: запуск на Debian з NGINX і підключення Grafana, але дані з Influx мігрував до VictoriaMetrics)
      • /usr/local/www – файли блогів
      • mysqldump – бекапи баз даних
      • vmbackup – дані VictoriaMetrics
      • бекапи блогу rtfm.co.ua – але в нього власна (дуже стара) система бекапів, яку поки не міняю – вона заливає дані в AWS S3, а вже звідти архіви нової системою зберігаються на NAS

Data Layers: діаграми збереження та передачі даних

Для кращого уявлення про те, як дані зберігаються та передаються – сформував такий собі концепт “Data Layers“:

  • Storage Layer: ZFS pool, datasets – тут визначаємо що і як зберігається
    • Snaphost Policy Layer: можна ввести додатковий рівень – тут визначаємо локальні ZFS snaphotting policy
  • Transport Layer: Rclone, Rsync – тут визначаємо що, чим, як і куди копіюється
  • Cloud Policy Layer: тут визначаємо які у нас є Rclone Remotes та encryption policy директорій і даних в них

Схема Transport Layer: передача та синхронізація даних

Тепер можна продумати та відобразити весь flow даних.

Про саму автоматизацію бекапів буду писати окремо, інакше пост буде кілометровий – там кілька shell-скриптів, які запускаються на NAS.

Але поки що можна схематично відобразити всі дані та процес збереження і передачі такою от діаграмою:

  • Syncthing: контролює дані, які змінюються не надто часто, мають мало “мусору”, та загальні для всіх хостів – постійно запущений процес на ноутбуках та телефоні
  • Rsync: для решти даних, має описані правила з include та exclude файлах – запускається з NAS, підключається до хостів, збирає з них дані
  • Rclone: займається копіювання даних в remotes, виконує шифрування – запускається з NAS після того, як rsync зібрав всі дані та сам backup-скрипт створив локальні (на NAS) бекапи WordPress та VictoriaMetrics

Схема Cloud Policy Layer: шифрування даних в Google Drive та Backblaze

Тут – для кращого розуміння самим собою – зібрав такий собі “mapping” даних із ZFS-датасетів на NAS до Rclone Remotes:

В Google Drive є окремий каталог Backups/Rclone, в якому створені окремі каталоги для кожного типу зберігання, і для кожного з них на NAS для Rclone налаштовані власні remotes:

  • /nas/services та /nas/systems: шифруємо самі дані, але імена каталогів та файлів plaintext, аби простіше було шукати
  • /nas/media: тут просто все відкритим текстом, бо нічого sensetive не маємо
  • /nas/vault та /nas/private: максимальний рівень конфіденційності – шифруються і імена каталогів та файлів, і їхній зміст

А для Backblaze – просто окремі корзини. Про Rclone remotes буде трохи далі.

NAS ZFS datasets: організація збереження даних

Далі для кожного класу даних визначив датасети:

  • Shared Static Unencrypted Data (~/Pictures, ~/Photos):
    • ZFS dataset: nas/media
  • Shared Dynamic Unencrypted Data (~/Work, ~/Projects, ~/Opt):
    • ZFS dataset: nas/media
  • Non-Shared Static Crypted Data (~/Films/Private/):
    • ZFS dataset: nas/private
  • Shared Static Crypted Data (~/Vault):
    • ZFS dataset: nas/vault
  • System Backups (/boot, /etc, /usr/local/etc):
    • ZFS dataset: nas/systems
  • Services Backups (WordPress databases та файли, VictoriaMetrics):
    • ZFS dataset nas/services

Всі ZFS datasets на NAS зараз виглядають так:

root@setevoy-nas:~ # zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
nas                 2.24T  1.27T   128K  /nas
nas/backups-manual   593G  1.27T   593G  /nas/backups-manual
nas/jellyfin        9.20G  1.27T  9.20G  /nas/jellyfin
nas/media            369G  1.27T   341G  /nas/media
nas/mobile          52.3G  1.27T  52.3G  /nas/mobile
nas/private          208G  1.27T   208G  /nas/private
nas/services         133G  1.27T   133G  /nas/services
nas/systems         4.82G  1.27T  3.78G  /nas/systems
nas/to-sort          560G  1.27T   560G  /nas/to-sort
nas/vault           56.2G  1.27T  56.2G  /nas/vault

Тут є кілька додаткових датасетів, які не пов’язані бекапами:

  • /nas/backups-manual: просто окремі ручні бекапи з хостів або з самого NAS, коли роблю якісь потенційно небезпечні операції з даними
  • /nas/jellyfin: фільми для Jellyfin (про нього є чорнетка, може якось допишу) – це чисто фільми-серіали, тому в бекапи не включено і зберігається окремо
  • /nas/mobile: датасет для даних з мобільного телефона, які копіюються сюди з Syncthing на телефоні
  • /nas/to-sort: копії даних зі старих компів, які треба перебрати та включити в загальні бекапи

Приклад організації даних системних бекапів – все по окремим каталогам:

root@setevoy-nas:~ # tree -d -L 3 /nas/systems/
/nas/systems/
├── setevoy-nas
│   └── thinkcentre-10SUSCF000
│       ├── boot
│       ├── etc
│       ├── home
│       ├── opt
│       ├── root
│       ├── usr
│       └── var
├── setevoy-pi
│   └── raspberry-pi-cm4-rev11
│       ├── etc
│       └── opt
└── setevoy-work
    └── thinkpad-t14-g5-21ML003URA
        ├── etc
        ├── home
        ├── root
        ├── usr
        └── var

І дані сервісів:

root@setevoy-nas:~ # tree -d -L 3 /nas/services/
/nas/services/
├── victoriametrics
│   ├── 20260222
│   │   ├── data
│   │   ├── indexdb
│   │   └── metadata
│   └── latest
│       ├── data
│       ├── indexdb
│       └── metadata
└── web
    └── setevoy
        ├── databases
        └── files

База VictoriaMetrics бекапиться з vmbackup, дані в web – скриптом, який створює tar.gz з файлами та запускає mysqldump для бекапів баз даних.

Дані на диску виглядають так:

root@setevoy-nas:~ # tree -L 4 /nas/services/
/nas/services/
├── victoriametrics
│   ├── 20260222
│   │   ├── backup_complete.ignore
│   │   ├── backup_metadata.ignore
│   │   ├── data
│   │   │   ├── indexdb
│   │   │   └── small
│   │   ├── indexdb
│   │   │   └── 1882B20388AAC712
│   │   └── metadata
│   │       └── minTimestampForCompositeIndex
│   └── latest
│       ├── backup_complete.ignore
│       ├── backup_metadata.ignore
│       ├── data
│       │   ├── indexdb
│       │   └── small
│       ├── indexdb
│       │   └── 1882B20388AAC712
│       └── metadata
│           └── minTimestampForCompositeIndex
└── web
    └── setevoy
        ├── databases
        │   ├── 2026-02-19-18-05-blog-setevoy.sql
        │   ├── 2026-02-21-18-47-blog-setevoy.sql
        │   ├── 2026-02-22-00-00-blog-setevoy.sql
        ...
        └── files
            ├── 2026-02-19-18-05-blog-setevoy.tar.gz
            ├── 2026-02-21-18-47-blog-setevoy.tar.gz
            ├── 2026-02-22-00-00-blog-setevoy.tar.gz
        ...
...

А дані в /nas/media – просто всі в одному каталозі:

root@setevoy-nas:~ # tree -L 3 /nas/media/
/nas/media/
└── home
    └── setevoy
        ├── Backups
        ├── Books
        ├── Documents
        ├── Downloads
        ├── Dropbox
        ├── Music
        ├── Opt
        ├── Photos
        ├── Pictures
        ├── Projects
        ├── VMs
        ├── Videos
        └── Work

Rclone remotes та пов’язані ZFS datasets

Для Rclone створені remotes під кожен датасет, з якого треба бекапити дані в клауди:

root@setevoy-nas:~ # rclone listremotes
nas-aws-s3-setevoy-backups-root:
nas-google-drive-total-root:
nas-google-drive-root:
nas-google-drive-media:
nas-google-drive-mobile:
nas-google-drive-crypted-systems:
nas-google-drive-crypted-services:
nas-google-drive-crypted-vault:
nas-google-drive-crypted-private:
nas-backblaze-root-media:
nas-backblaze-crypted-media:
nas-backblaze-root-mobile:
nas-backblaze-crypted-mobile:
nas-backblaze-root-systems:
nas-backblaze-crypted-systems:
nas-backblaze-root-services:
nas-backblaze-crypted-services:
nas-backblaze-root-vault:
nas-backblaze-crypted-vault:
nas-backblaze-root-private:
nas-backblaze-crypted-private:

Кожен remote “мапиться” на ZFS datasets:

  • nas-google-drive-media та nas-backblaze-crypted-media: сюди заливаються дані з /nas/media
  • nas-google-drive-crypted-systems та nas-backblaze-crypted-systems: сюди – з /nas/systems

І так далі.

Кожен Rclone Remote має власну директорію в Google Drive або Backblaze бакет.

В Google Drive це виглядає так:

root@setevoy-nas:~ # rclone tree -d --max-depth 2  nas-google-drive-total-root:Backups/Rclone
/
└── nas
    ├── media
    ├── mobile
    ├── private
    ├── services
    ├── systems
    └── vault

І приклад одного з бакетів в Backblaze:

root@setevoy-nas:~ # rclone tree -d --max-depth 4 nas-backblaze-crypted-media:
/
├── _archive
│   ├── 2026-02-22-14-53
│   ├── 2026-02-24-03-06
│   │   └── home
│   │       └── setevoy
│   ├── 2026-02-25-03-07
│   │   └── home
│   │       └── setevoy
│   └── 2026-02-27-12-18
│       └── home
│           └── setevoy
└── data
    └── home
        └── setevoy
            ├── Backups
            ├── Books
            ├── Documents
            ├── Downloads
            ├── Dropbox
            ├── Music
            ├── Opt
            ├── Photos
            ├── Pictures
            ├── Projects
            ├── VMs
            ├── Videos
            └── Work

Ну, наче все описав.

Наступна частина – про сам shell-скрипт, який запускає rsync, створює бекапи WordPress та VictoriaMetrics, потім створює ZTS snapshots, а потім всі дані синхронізує в Rclone remotes.

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

Loading