FreeBSD: Home NAS, part 8 – backup даних NFS та Samba з restic
0 (0)

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

Власне, по налаштуванню NAS вже зроблено майже все – з VPN є доступи з різних мереж, є різні шари, трохи затюнили безпеку.

Залишилось дві основні речі: моніторинг і бекапи, бо мати ZFS mirror на двох дисках з регулярними ZFS snapshots це, звісно, класно, але все одно недостатньо, а тому хочеться додатково робити бекапи десь в клауд.

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

Сьогодні подумаємо і заплануємо як робити бекапи з Linux-хостів на NFS share та як робити бекапи даних NFS і Samba на FreeBSD. При чому бекапи хочеться зробити у два незалежних сховища – AWS S3 та Google Disk: S3 буде основним, а Гугл – резервною копією (резервної копії).

Всі пости цієї серії:

Планування бекапів

Отже, що в мене є:

  • Linux-хости: домашній і робочий ноутбуки – всякі фото, відео, музика, робочі дані, документи, ключі SSH/GPG/etc, конфіги самої системи
  • FreeBSD-хост: тут живуть Samba та NFS shares і маємо системні дані, які треба зберігати

NFS-шари підключаються до Linux-хостів, які сюди будуть робити бекапи, а потім вже з FreeBSD ці бекапи копіюються до AWS S3 та Google Drive.

Якщо це відобразити схематично, то виходить така картина:

FreeBSD backup plan

Якщо з ноутбуками і Linxu все більш-менш просто – бекапимо важливі дані із /home/setevoy, то з FreeBSD краще продумати окремо, бо тут даних більше:

  • /nas/nfs/backups: бекапи Linux-хостів – треба зберігати копії в клауд
  • /nas/smb: тут два датасети – /nas/smb/media зі всякими музикою-фільмами, та /nas/smb/private з приватними даними, обидва теж зберігати в клауд
  • плюс системні бекапи самої FreeBSD

В системний бекап FreeBSD можна включити:

  • /etc та /usr/local/etc: завжди мати копію всіх конфігураційних файлів
  • /root: якщо там файли типу nas-private-pass.key, яким в мене шифрується і монтується один з датасетів
  • /var/db: pkg і jails metadata, sqlite/db файли деяких сервісів

Вибір утиліт для бекапу

Спочатку думав взяти Timeshift, але, як виявилось, він не вміє в remote storage і не може зберігати на NFS.

А тому треба вибирати щось під мої потреби:

  • мультиплатформа – FreeBSD, Linux, Windows
  • вміти в повне і інкрементальне копіювання
  • мати можливість через конфіг-файл задавати список директорій та файлів, які треба бекапити або пропускати
  • must have – CLI
  • опціонально – мати Web або звичайний GUI
  • вмісти працювати як з локальними файловими системами – так і з NFS або Samba, і на додачу – вміти працювати з клаудами
  • коректно працювати з правами доступу та ACL файлової системи, бо файлові системі різні
  • опціонально – вміти шифрувати бекапи

З тих варіантів, що передивився – найбільше сподобався restic, тож вирішив спробувати його.

Restic overview

Вся його документація – Restic Documentation та Manual.

Основні плюшки restic:

  • написаний на Golang, див GitHub restic
  • доволі простий синтаксис команд для CLI
  • шифрування та data compression з коробки
  • інкрементальні бекапи через власні снапшоти
  • з коробки вміє працювати з NFS та AWS S3, див. Storage Backends.
  • може працювати з іншими бекендами через rclone, а вже rclone має просто безліч варіантів бекендів (див. Supported providers)
  • є third-party Web UI – Backrest
  • є клієнти під всі системи – Linux, FreeBSD, macOS, Windows (див. Installation)

Встановлюємо на Arch Linux:

$ sudo pacman -S restic

Та на FreeBSD:

# pkg install restic

Приклади в цьому пості будуть з Linux, але принципової різниці нема – клієнт працює однаково на всіх платформах.

Restic repositories та snapshots

Документація – Preparing a new repository та Repository Format.

Дані в restic організовані у репозиторіях: кожен репозиторій – це окремий каталог, який містить конфігурацію репозиторію, індекси та зашифровані дані.

Під час створення бекапу restic формує власні логічні snapshots. Дані розбиваються на незалежні блоки (blobs), які і є базовими одиницями зберігання в репозиторії.

При наступних бекапах restic перевіряє, які саме блоки були змінені, і копіює тільки їх, а на блоки даних, які не змінились – створює посилання з нового снапшоту, таким чином оптимізуючи зайнятий дисковий простір.

Тобто тут процес  схожий із ZFS snapshots – тільки у ZFS посилання створюється на блоки самої файлової системи і оригінальні дані, а в restic – на власні блоки даних в каталозі репозиторію.

При цьому restic зберігає дані у власному форматі, а тому ми не залежимо від файлової системи – створюємо бекап з ext4, копіюємо на ZFS, зберігаємо в S3, і відновлюємо на упасі боже Windows з NTFS. Єдине, що нам буде треба – це клієнт restic.

Створюємо тестовий репозиторій:

$ restic init --repo test-repo
enter password for new repository: 
enter password again: 
created restic repository 50ef450308 at test-repo

Перевіряємо зміст:

$ ll test-repo/
total 24
-r--------   1 setevoy setevoy  155 Jan  1 16:47 config
drwx------ 258 setevoy setevoy 4096 Jan  1 16:47 data
drwx------   2 setevoy setevoy 4096 Jan  1 16:47 index
drwx------   2 setevoy setevoy 4096 Jan  1 16:47 keys
drwx------   2 setevoy setevoy 4096 Jan  1 16:47 locks
drwx------   2 setevoy setevoy 4096 Jan  1 16:47 snapshots

Restic та шифрування даних

Документація – Keys, Encryption and MAC.

Кожен репозиторій має ключ, який використовується для доступу до зашифрованих даних:

$ restic key list --repo test-repo
enter password for repository: 
repository 50ef4503 opened (version 2, compression level auto)
 ID        User     Host          Created
-----------------------------------------------------
*0ca1c659  setevoy  setevoy-work  2026-01-01 16:49:49
-----------------------------------------------------

Шифрування даних виконується з master key, який зберігається в репозиторії:

$ restic -r test-repo cat masterkey
enter password for repository: 
repository 50ef4503 opened (version 2, compression level auto)
{
  "mac": {
    "k": "v1PIB3bB1VW46oWWBtKQYA==",
    "r": "Tia4a7HGs7PmN1EzWoWh4g=="
  },
  "encrypt": "0c3l/00P3dTgdbAqPZApAYn7E/MiloqOXyQsYr6AGOA="
}

Для отримання доступу до якого використовуються дані user keys:

$ cat test-repo/keys/0ca***f3a | jq
{
  "created": "2026-01-01T16:49:49.010471345+02:00",
  "username": "setevoy",
  "hostname": "setevoy-work",
  "kdf": "scrypt",
  "N": 32768,
  "r": 8,
  "p": 9,
  "salt": "F3G***50Q==",
  "data": "rjw***FLQ=="
}

Тут:

  • scrypt: KDF (Key Derivation Function), яка використовується для отримання криптографічного ключа з пароля (див. Scrypt Key Derivation Function)
  • salt: сіль з рандомним значенням
  • data: зашифрований master key – саме він використовується для шифрування даних

Коли restic потрібно отримати доступ до даних у репозиторії – він бере введений пароль і salt, передає їх у KDF і формує ключ, який використовується для розшифрування master key репозиторію.

Master key, у свою чергу, застосовується для шифрування та розшифрування ключів, якими вже безпосередньо шифруються дані та метадані в репозиторії.

При цьому можна мати кілька різних user keys (або access keys), які будуть використовуватись для отримання master key.

При потребі пароль можна змінити:

$ restic key passwd --repo test-repo/
enter password for repository: 
repository 50ef4503 opened (version 2, compression level auto)
created new cache in /home/setevoy/.cache/restic
enter new password: 
enter password again: 
saved new key as <Key of setevoy@setevoy-work, created on 2026-01-01 16:49:49.010471345 +0200 EET m=+13.105722833>

При налаштуванні автоматизації бекапів – пароль можна передати зі змінної оточення RESTIC_PASSWORD (див. Environment Variables) або з файлу через --password-file.

Наприклад, для використання паролю з файлу – створимо директорію:

$ mkdir -p ~/.config/restic-test
$ chmod 700 ~/.config/restic-test/

Генеруємо пароль:

$ pwgen 32 1
xoo8eibia2ohch7Oat7zeeshahn0keic

І зберігаємо його в файл ~/.config/restic-test/test-repo-password.

Задаємо доступ на читання тільки власнику:

$ chmod 600 ~/.config/restic-test/test-repo-password

Додаємо новий ключ для репозиторію:

$ restic key add --repo test-repo
enter password for repository: 
repository 50ef4503 opened (version 2, compression level auto)
enter new password: 
enter password again: 
saved new key with ID c08c993b87363c17526e98fd46aeaf14767fa051e3b0d87a32c0cecc50e361d4

Перевіряємо ключі тепер:

[setevoy@setevoy-work ~/Projects/Restic]  $ restic key list --repo test-repo
enter password for repository: 
repository 50ef4503 opened (version 2, compression level auto)
 ID        User     Host          Created
-----------------------------------------------------
*0ca1c659  setevoy  setevoy-work  2026-01-01 16:49:49
 c08c993b  setevoy  setevoy-work  2026-01-01 17:02:10
-----------------------------------------------------

В *0ca1c659 зірочка показує, що зараз репозиторій відкритий з цим ключем.

Пробуємо відкрити з новим ключем – паролем з файла:

$ restic stats --repo test-repo --password-file ~/.config/restic-test/test-repo-password
repository 50ef4503 opened (version 2, compression level auto)
[0:00]          0 index files loaded
scanning...
Stats in restore-size mode:
     Snapshots processed:  0
              Total Size:  0 B

Restic backup та restore

Документація – Backing up.

Для створення бекапів використовуємо команду restic backup, а для відновлення, власне, restic restore.

Бекапимо файл /tmp/restic-test.txt в наш репозиторій:

$ restic backup /tmp/restic-test.txt --repo test-repo
repository 50ef4503 opened (version 2, compression level auto)
no parent snapshot found, will read all files
[0:00]          0 index files loaded

Files:           1 new,     0 changed,     0 unmodified
Dirs:            1 new,     0 changed,     0 unmodified
Added to the repository: 755 B (687 B stored)

processed 1 files, 13 B in 0:01
snapshot bf8def5f saved

Під час кожного виклику restic backup в репозиторії створюється новий snapshot, навіть якщо дані в source не змінювались.

Але, як писав вище – якщо не змінюються дані, то і розмір репозиторію не росте, бо restic просто створить посилання з нового снапшоту на старі блоки даних.

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

Перевіряємо наявні снапшоти:

$ restic snapshots --repo test-repo
repository 50ef4503 opened (version 2, compression level auto)
ID        Time                 Host          Tags        Paths                 Size
-----------------------------------------------------------------------------------
bf8def5f  2026-01-01 17:07:53  setevoy-work              /tmp/restic-test.txt  13 B
-----------------------------------------------------------------------------------
1 snapshots

Основні корисні команди при роботі з репозиторіями та снапшотами:

  • restic stats: статистика по репозиторію або снапшоту
  • restic check: перевірка цілісності репозиторію
  • restic ls: подивитись зміст снапшоту
  • restic diff: порівняти дані у двох снапшотах
  • restic copy: скопіювати зміст одного репозиторію в інший

І окремо варто згадати --dry-run – перевірити що саме буде виконуватись, і яких даних торкнеться операція.

Для відновлення даних з бекапу використовуємо restic restore і вказуємо ID снапшоту та куди його відновити.

Якщо в destination каталогу нема – restic його створить, а в ньому відновить ієрархію каталогів та файлів зі снапшоту:

$ restic restore --repo test-repo bf8def5f --target /tmp/test-restic-restore
...
restoring snapshot bf8def5f of [/tmp/restic-test.txt] at 2026-01-01 17:07:53.016664301 +0200 EET by setevoy@setevoy-work to /tmp/test-restic-restore
Summary: Restored 2 files/dirs (13 B) in 0:00

Перевіряємо:

$ tree /tmp/test-restic-restore
/tmp/test-restic-restore
└── tmp
    └── restic-test.txt

Include та exclude для backup та restore

При створенні бекапу з restic backup ми вказуємо шлях, який бекапиться, а тому окремої опції --include нема.

Але є --exclude, з яким можна вказати які дані не треба включати в снапшот.

Наприклад, маємо каталог:

$ tree /tmp/restic-dir-test
/tmp/restic-dir-test
├── a.txt
└── sub
    └── b.txt

Бекапимо весь цей каталог, але пропускаємо файл a.txt:

$ restic backup /tmp/restic-dir-test --exclude /tmp/restic-dir-test/a.txt --repo test-repo

Дивимось в снапшоті – a.txt нема:

$ restic ls dfd8271d --repo test-repo
...
/tmp
/tmp/restic-dir-test
/tmp/restic-dir-test/sub
/tmp/restic-dir-test/sub/b.txt

Для restic restore можемо вказати як --include – що саме відновити, так і --exclude – які дані зі снапшота пропустити.

Замість передачі include/exclude в CLI можна всі шляхи описати в файлах, по одному на строку, див. Including Files та Excluding Files.

У файлах можна використовувати коментарі та пусті строки, наприклад, файл backup-nfs.list:

# MAIN
/home/setevoy/Photos
...

# dotdirs
/home/setevoy/.aws
...

Потім викликаємо як:

  • restic backup --files-from backup-nfs.list -r <REPO_NAME>
  • restic backup --files-from backup-nfs.list --exclude-file exclude-nfs.list -r <REPO_NAME>

І аналогічно з restic restore та --include-file і --exclude-file.

Крім того, в include та exclude можна використовувати globbing (не regex):

  • *: – будь-яка послідовність символів в межах одного рівня каталогу
    • приклад: *.log, cache/*
  • **: будь-яка кількість каталогів рекурсивно
    • приклад: **/data, /home/**/cache
  • ?: один будь-який символ
    • приклад: file?.txt
  • [abc]: один символ з набору
    • приклад: file[12].txt
  • [a-z]: діапазон символів
    • приклад: img[0-9].jpg
  • !pattern: інверсія правила (тільки у файлах include/exclude)

Теги для снапшотів

При створенні снапшотів в ZFS ми можемо вказати його ім’я через @.

В restic снапшоти зберігаються тільки з ID – але до них можна додати теги:

$ restic backup /tmp/restic-dir-test --repo test-repo --tag "daily" --tag "$(date +"%Y-%m-%d-%H-%M")"

Далі по цим тегам можна виконувати пошук, copy, restore, forget (про forget далі).

Наприклад, вивести тільки снапшоти з тегом daily:

$ restic snapshots --tag daily -r test-repo
repository 50ef4503 opened (version 2, compression level auto)
ID        Time                 Host          Tags                    Paths                 Size
-----------------------------------------------------------------------------------------------
d14ecde9  2026-01-04 15:08:41  setevoy-work  daily,2026-01-04-15-08  /tmp/restic-dir-test  18 B
-----------------------------------------------------------------------------------------------

Видалення снапшотів з forget та prune

Документація – Removing backup snapshots.

Для очистки даних restic використовуємо команди forget та prune:

  • restic forget: знімає посилання снапшота на блоки даних – але не видаляє їх
  • restic prune: видаляє самі дані – блоки, на які нема посилань зі снапшотів

Наприклад:

$ restic forget f3ce1ac3 -r test-repo
repository 50ef4503 opened (version 2, compression level auto)
[0:00] 100.00%  1 / 1 files deleted

Або відразу виконати prune через restic forget --prune:

$ restic forget 45e6f909 -r test-repo --prune
repository 50ef4503 opened (version 2, compression level auto)
[0:00] 100.00%  1 / 1 files deleted
1 snapshots have been removed, running prune
loading indexes...
[0:00] 100.00%  7 / 7 index files loaded
loading all snapshots...
finding data that is still in use for 5 snapshots
[0:00] 100.00%  5 / 5 snapshots
...
repacking packs
[0:00] 100.00%  1 / 1 packs repacked
rebuilding index
[0:00] 100.00%  8 / 8 indexes processed
[0:00] 100.00%  8 / 8 old indexes deleted
removing 2 old packs
[0:00] 100.00%  2 / 2 files deleted
done

Замість snapshot ID можна вказати policy, див. Removing snapshots according to a policy.

Наприклад:

$ restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --tag daily --prune -r test-repo
repository 50ef4503 opened (version 2, compression level auto)
Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots
keep 1 snapshots:
ID        Time                 Host          Tags                    Reasons           Paths                 Size
-----------------------------------------------------------------------------------------------------------------
d14ecde9  2026-01-04 15:08:41  setevoy-work  daily,2026-01-04-15-08  daily snapshot    /tmp/restic-dir-test  18 B
                                                                     weekly snapshot
                                                                     monthly snapshot
-----------------------------------------------------------------------------------------------------------------

Тут:

  • --keep-daily 7: залишаємо снапшоти за останні 7 днів
  • --keep-weekly 4: залишаємо снапшоти за останні 4 тижні (по одному snapshot на тиждень)
  • --keep-monthly 6: залишаємо снапшоти за останні 6 місяців (по одному snapshot на місяць)
  • застосовуємо тільки для снапшотів з тегом daily, і відразу видаляємо дані з диску

Restic mount – репозиторій як директорія

Можна змонтувати репозиторій як звичайну папку, монтується тільки в режимі read-only:

$ mkdir /tmp/restic-mounted-test-repo

$ restic mount -r test-repo /tmp/restic-mounted-test-repo
...
Now serving the repository at /tmp/restic-mounted-test-repo
...

І отримуємо доступ до даних в усіх снапшотах:

$ tree /tmp/restic-mounted-test-repo
/tmp/restic-mounted-test-repo
├── hosts
│   └── setevoy-work
│       ├── 2026-01-01T17:07:53+02:00
│       │   └── tmp
│       │       └── restic-test.txt
...
├── ids
│   ├── 0f477146
│   │   └── tmp
│   │       └── restic-dir-test
│   │           └── sub
│   │               └── b.txt
...
├── snapshots
│   ├── 2026-01-01T17:07:53+02:00
│   │   └── tmp
│   │       └── restic-test.txt
...

Але це можливість більше для якогось ручного дебагу-фіксу, а не для автоматизації.

Restic copy – копіювання даних між репозиторіями

Для копіювання одного репозиторію в інший використовуємо restic copy, див. Copying snapshots between repositories.

Наприклад, так можна копіювати бекапи з репозиторіїв у NFS на FreeBSD до репозиторіїв в AWS S3 та Google Drive.

По-дефолту restic copy скопіює всі снапшоти із source repo, але можна вказати які саме снапшоти копіювати.

Створюємо новий пустий репозиторій:

$ restic init -r new-test-repo

Копіюємо один снапшот зі старого репозиторію:

$ restic copy --from-repo test-repo --repo new-test-repo d14ecde9

Або всі снапшоти з тегом daily:

$ restic copy --from-repo test-repo --repo new-test-repo --tag daily

Тепер в новому репозиторії маємо ті самі дані:

 $ restic snapshots -r new-test-repo
repository fc8a407c opened (version 2, compression level auto)
ID        Time                 Host          Tags                    Paths                 Size
-----------------------------------------------------------------------------------------------
7335e7bf  2026-01-04 15:08:41  setevoy-work  daily,2026-01-04-15-08  /tmp/restic-dir-test  18 B
-----------------------------------------------------------------------------------------------

Restic та репозиторій в AWS S3

З S3 все більш-менш аналогічно до роботи з локальними репозиторіями, але є деякі нюанси.

Для аутентифікації restic використовує звичайний механізм – пошук змінних оточення AWS_ACCESS_KEY_ID та AWS_SECRET_ACCESS_KEY, або пошук у файлах ~/.aws/config та ~/.aws/credentials.

Задаємо змінні:

$ export AWS_PROFILE=setevoy
$ export AWS_DEFAULT_REGION=eu-west-1

В AWS створюємо корзину, а потім ініціалізуємо в ній репозиторій, використовуючи формат s3:s3.amazonaws.com/<BUCKET_NAME>/<REPO_NAME>:

$ restic init --repo s3:s3.amazonaws.com/test-restic-repo-bucket/test-restic-repository
created restic repository 58303a9c88 at s3:s3.amazonaws.com/test-restic-repo-bucket/test-restic-repository

Перевіряємо корзину:

$ aws s3 ls s3://test-restic-repo-bucket --recursive
2026-01-04 16:11:28        155 test-restic-repository/config
2026-01-04 16:11:28        457 test-restic-repository/keys/e53...22f

Важливі нюанси, які треба мати на увазі при роботі з S3:

  • видаляти дані з репозиторію restic в AWS S3 можна тільки через restic forget та restic prune
  • використання S3 Lifecycle rules для restic не рекомендується – навіть для зміни storage class

Каталоги (index/, snapshots/, keys/) активно використовуються restic; якщо перенести, наприклад, keys/ у Glacier або Deep Archive – restic може зависати або падати по таймауту, очікуючи доступ до ключів.

Теоретично lifecycle transitions можна застосувати лише до каталогу data/, де зберігаються pack-файли з даними, але якщо потім запустити restic prune – то restic буде потрібен доступ до старих pack-файлів в data/, і, якщо вони знаходяться в Glacier або Deep Archive, операція стане або дуже повільною, або взагалі неможливою

Тому краще просто робити періодичний restic forget і restic prune, та залишити S3 Standart class даних в бакеті.

Restic та Google Drive через rclone

В мене rclone для Google Drive вже налаштований, допишу про нього окремо, вже є в чернетках, бо теж дуже цікава система.

Що ми можемо зробити – це використати rclone як storage backend для роботи з типами storage, яких нема в самому restic.

Але працює ця схема ну дуже повільно (принаймні з Google Drive) – тому її краще використовувати як one time copy, а не для регулярних бекапів.

Документація – rclone serve restic.

Наприклад, є rclone profile:

$ rclone config show
[setevoy-google-drive]
type = drive
...

Через який я можу підключатись до Google Disk:

$ rclone lsd setevoy-google-drive:
           0 2025-04-16 16:32:56        -1 Arch_Old_Music
           0 2025-04-16 16:50:53        -1 Arch_Work_Photos
           0 2020-06-19 22:13:53        -1 BackendParty-2020-06
...

Створюємо там новий каталог restic-rclone-gdrive-repo:

$ rclone mkdir setevoy-google-drive:restic-rclone-gdrive-repo

З rclone serve restic запускаємо локальний HTTP enpoint нового бекенду для restic вказуючи створений вище каталог – це вже буде корінь репозиторію:

$ rclone serve restic setevoy-google-drive:restic-rclone-gdrive-repo
2026/01/04 16:39:34 NOTICE: Google drive root 'restic-rclone-gdrive-repo': Serving restic REST API on [http://127.0.0.1:8080/]

В іншому вікні для restic задаємо змінну нового ендпоінта:

$ export RESTIC_REPOSITORY=rest:http://127.0.0.1:8080/

Виконуємо ініціалізацію цього репозиторію:

$ restic init
enter password for new repository: 
enter password again: 
created restic repository e1a8edaebd at rest:http://127.0.0.1:8080/

Перевіряємо дані в Google Drive:

$ rclone lsd setevoy-google-drive:restic-rclone-gdrive-repo
           0 2026-01-04 16:42:08        -1 data
           0 2026-01-04 16:42:09        -1 index
           0 2026-01-04 16:42:10        -1 keys
           0 2026-01-04 16:42:11        -1 locks
           0 2026-01-04 16:42:12        -1 snapshots

І скопіюємо дані з AWS S3 до репозиторію в Google Drive

Задаємо змінні:

$ export AWS_PROFILE=setevoy
$ export AWS_DEFAULT_REGION=eu-west-1
$ export RESTIC_REPOSITORY=rest:http://127.0.0.1:8080/

Запускаємо restic copy, але тепер для copy вказуємо тільки --from-repo – бо destination у нас вже заданий через $RESTIC_REPOSITORY:

$ restic copy --from-repo s3:s3.amazonaws.com/test-restic-repo-bucket/test-restic-repository
enter password for source repository: 
repository 58303a9c opened (version 2, compression level auto)
created new cache in /home/setevoy/.cache/restic
enter password for repository: 
repository e1a8edae opened (version 2, compression level auto)
created new cache in /home/setevoy/.cache/restic
[0:00]          0 index files loaded
[0:00]          0 index files loaded

Перевіряємо в Google Drive:

$ restic snapshots 
enter password for repository: 
repository e1a8edae opened (version 2, compression level auto)
ID        Time                 Host          Tags                    Paths                 Size
-----------------------------------------------------------------------------------------------
...
bb02e44b  2026-01-04 15:08:41  setevoy-work  daily,2026-01-04-15-08  /tmp/restic-dir-test  18 B
-----------------------------------------------------------------------------------------------

Що треба мати на увазі при роботі restic через clone:

  • не використовувати rclone mount
  • не виконувати запис одночасно з двох restic клієнтів
  • не використовувати одночасно два rclone serve restic для одного репозиторію

Власне, на цьому все.

Залишилось додати автоматизацію запуску бекапів на Linux та FreeBSD, але це вже опишу окремим постом.

На додачу – документація по тюнингу restic: Tuning Backup Parameters.

Loading