2025-12-13 19:34:07 +01:00
|
|
|
|
Name{number}
|
|
|
|
|
|
snapraid - SnapRAID Резервне копіювання для дискових масивів
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Короткий опис (Synopsis)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
:snapraid [-c, --conf CONFIG]
|
|
|
|
|
|
: [-f, --filter PATTERN] [-d, --filter-disk NAME]
|
|
|
|
|
|
: [-m, --filter-missing] [-e, --filter-error]
|
|
|
|
|
|
: [-a, --audit-only] [-h, --pre-hash] [-i, --import DIR]
|
|
|
|
|
|
: [-p, --plan PERC|bad|new|full]
|
|
|
|
|
|
: [-o, --older-than DAYS] [-l, --log FILE]
|
|
|
|
|
|
: [-s, --spin-down-on-error] [-w, --bw-limit RATE]
|
2026-03-16 23:43:14 +01:00
|
|
|
|
: [-t, --tail]
|
2025-12-13 19:34:07 +01:00
|
|
|
|
: [-Z, --force-zero] [-E, --force-empty]
|
|
|
|
|
|
: [-U, --force-uuid] [-D, --force-device]
|
|
|
|
|
|
: [-N, --force-nocopy] [-F, --force-full]
|
2026-03-16 23:43:14 +01:00
|
|
|
|
: [-R, --force-realloc] [-W, --force-realloc-tail]
|
2025-12-13 19:34:07 +01:00
|
|
|
|
: [-S, --start BLKSTART] [-B, --count BLKCOUNT]
|
|
|
|
|
|
: [-L, --error-limit NUMBER]
|
|
|
|
|
|
: [-A, --stats]
|
|
|
|
|
|
: [-v, --verbose] [-q, --quiet]
|
|
|
|
|
|
: status|smart|probe|up|down|diff|sync|scrub|fix|check
|
2026-02-25 14:48:54 +01:00
|
|
|
|
: |list|dup|pool|devices|touch|rehash|locate
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
:snapraid [-V, --version] [-H, --help] [-C, --gen-conf CONTENT]
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Опис (Description)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
SnapRAID — це програма резервного копіювання, розроблена для
|
|
|
|
|
|
дискових масивів, яка зберігає інформацію парності для
|
|
|
|
|
|
відновлення даних у випадку відмови до шести дисків.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Насамперед призначений для домашніх медіацентрів з великими
|
|
|
|
|
|
файлами, які рідко змінюються, SnapRAID пропонує кілька функцій:
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
* Ви можете використовувати диски, вже заповнені файлами, без
|
|
|
|
|
|
необхідності їх переформатування, отримуючи доступ до них
|
|
|
|
|
|
як зазвичай.
|
|
|
|
|
|
* Усі ваші дані хешуються для забезпечення цілісності даних
|
|
|
|
|
|
та запобігання прихованому пошкодженню.
|
|
|
|
|
|
* Коли кількість дисків, що відмовили, перевищує кількість
|
|
|
|
|
|
дисків парності, втрата даних обмежується дисками, що
|
|
|
|
|
|
постраждали; дані на інших дисках залишаються доступними.
|
|
|
|
|
|
* Якщо ви випадково видалили файли на диску, можливе
|
|
|
|
|
|
відновлення.
|
|
|
|
|
|
* Диски можуть мати різний розмір.
|
|
|
|
|
|
* Ви можете додавати диски в будь-який час.
|
|
|
|
|
|
* SnapRAID не блокує ваші дані; ви можете припинити його
|
|
|
|
|
|
використання в будь-який час без переформатування або
|
|
|
|
|
|
переміщення даних.
|
|
|
|
|
|
* Для доступу до файлу потрібно розкрутити лише один диск, що
|
|
|
|
|
|
заощаджує електроенергію та зменшує шум.
|
|
|
|
|
|
|
|
|
|
|
|
Для отримання додаткової інформації відвідайте офіційний сайт
|
|
|
|
|
|
SnapRAID:
|
|
|
|
|
|
|
|
|
|
|
|
:https://www.snapraid.it/
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Обмеження (Limitations)
|
2026-06-08 18:26:17 +02:00
|
|
|
|
SnapRAID є гібридом між RAID і програмою резервного копіювання, що має на меті поєднати
|
|
|
|
|
|
найкращі переваги обох рішень. Однак у нього є деякі обмеження, які вам слід
|
|
|
|
|
|
врахувати перед використанням.
|
|
|
|
|
|
|
|
|
|
|
|
Головне обмеження полягає в тому, що у разі збою диска ви можете відновити дані лише до
|
|
|
|
|
|
стану останньої операції синхронізації (`sync`). Будь-які дані, додані або змінені
|
|
|
|
|
|
з моменту останньої синхронізації, які розташовані на пошкодженому диску, будуть втрачені.
|
|
|
|
|
|
|
|
|
|
|
|
Відповідно, SnapRAID насамперед підходить для даних, які рідко змінюються.
|
|
|
|
|
|
|
|
|
|
|
|
Для даних, які вже існували на момент останньої синхронізації, надійність відновлення залежить
|
|
|
|
|
|
від того, чи використовується опція знімка (`snapshot`):
|
|
|
|
|
|
|
|
|
|
|
|
* За наявності підтримки знімків (доступно на Btrfs, ZFS, Bcachefs та NTFS),
|
2026-08-12 14:53:58 +02:00
|
|
|
|
SnapRAID може автоматично підтримувати незалежну заморожену копію
|
|
|
|
|
|
кожної підтримуваної файлової системи даних.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Це гарантує, що навіть якщо ви зміните або видалите файли у вашій живій файловій системі
|
|
|
|
|
|
під час або після синхронізації, процес відновлення залишиться узгодженим і надійним.
|
|
|
|
|
|
|
|
|
|
|
|
* Без підтримки знімків видалення або зміна файлів після `sync`
|
|
|
|
|
|
може запобігти повному відновленню інших дисків, що зазнали збою. Це відбувається
|
|
|
|
|
|
тому, що парність більше не відповідає зміненим файлам, навіть якщо
|
|
|
|
|
|
ці файли знаходяться не на пошкодженому диску. З іншого боку, щойно додані
|
|
|
|
|
|
файли не перешкоджають відновленню вже існуючих файлів.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Інші обмеження SnapRAID:
|
|
|
|
|
|
|
|
|
|
|
|
* З SnapRAID у вас все ще є окремі файлові системи для
|
|
|
|
|
|
кожного диска. З RAID ви отримуєте одну велику файлову
|
|
|
|
|
|
систему.
|
|
|
|
|
|
* SnapRAID не використовує чергування (striping) даних.
|
|
|
|
|
|
З RAID ви отримуєте прискорення завдяки чергуванню.
|
|
|
|
|
|
* SnapRAID не підтримує відновлення в реальному часі.
|
|
|
|
|
|
З RAID вам не потрібно припиняти роботу, коли диск
|
|
|
|
|
|
виходить з ладу.
|
|
|
|
|
|
* SnapRAID може відновлювати дані лише з обмеженої кількості
|
|
|
|
|
|
дисків, що вийшли з ладу. З резервним копіюванням ви
|
|
|
|
|
|
можете відновити дані навіть після повної відмови
|
|
|
|
|
|
всього дискового масиву.
|
|
|
|
|
|
* Зберігаються лише імена файлів, часові мітки, символічні
|
2026-06-25 23:08:58 +02:00
|
|
|
|
та жорсткі посилання. Права доступу, власники та
|
2025-12-13 19:34:07 +01:00
|
|
|
|
розширені атрибути не зберігаються.
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Початок роботи (Getting Started)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Щоб використовувати SnapRAID, спершу потрібно вибрати один диск
|
|
|
|
|
|
у вашому дисковому масиві, щоб присвятити його інформації
|
|
|
|
|
|
`парності`. З одним диском для парності ви зможете відновити
|
|
|
|
|
|
дані після відмови одного диска, подібно до RAID5.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви хочете відновити дані після більшої кількості
|
|
|
|
|
|
дисків, що відмовили, подібно до RAID6, ви повинні зарезервувати
|
|
|
|
|
|
додаткові диски для парності. Кожен додатковий диск парності
|
|
|
|
|
|
дозволяє відновити дані після відмови ще одного диска.
|
|
|
|
|
|
|
|
|
|
|
|
Як диски парності ви повинні вибрати найбільші диски в масиві,
|
|
|
|
|
|
оскільки інформація парності може зрости до розміру найбільшого
|
|
|
|
|
|
диска даних у масиві.
|
|
|
|
|
|
|
|
|
|
|
|
Ці диски будуть присвячені зберіганню файлів `парності`. Ви
|
|
|
|
|
|
не повинні зберігати на них свої дані.
|
|
|
|
|
|
|
|
|
|
|
|
Потім ви повинні визначити диски `даних`, які ви хочете
|
|
|
|
|
|
захистити за допомогою SnapRAID. Захист є більш ефективним,
|
|
|
|
|
|
якщо ці диски містять дані, що рідко змінюються. З цієї причини
|
|
|
|
|
|
краще НЕ включати диск Windows C:\ або каталоги Unix /home,
|
|
|
|
|
|
/var та /tmp.
|
|
|
|
|
|
|
|
|
|
|
|
Список файлів зберігається у файлах `content` (вміст), які
|
|
|
|
|
|
зазвичай зберігаються на дисках даних, парності або завантажувальних
|
|
|
|
|
|
дисках.
|
|
|
|
|
|
Цей файл містить деталі вашої резервної копії, включаючи
|
|
|
|
|
|
всі контрольні суми для перевірки її цілісності.
|
|
|
|
|
|
Файл `content` зберігається в кількох копіях, і кожна копія
|
|
|
|
|
|
повинна бути на окремому диску, щоб гарантувати, що навіть у
|
|
|
|
|
|
разі відмови кількох дисків, принаймні одна копія буде доступна.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, припустимо, вас цікавить лише один рівень захисту
|
|
|
|
|
|
парності, а ваші диски розташовані за адресами:
|
|
|
|
|
|
|
|
|
|
|
|
:/mnt/diskp <- вибраний диск для парності
|
|
|
|
|
|
:/mnt/disk1 <- перший диск для захисту
|
|
|
|
|
|
:/mnt/disk2 <- другий диск для захисту
|
|
|
|
|
|
:/mnt/disk3 <- третій диск для захисту
|
|
|
|
|
|
|
|
|
|
|
|
Ви повинні створити конфігураційний файл /etc/snapraid.conf з
|
|
|
|
|
|
наступними опціями:
|
|
|
|
|
|
|
|
|
|
|
|
:parity /mnt/diskp/snapraid.parity
|
|
|
|
|
|
:content /var/snapraid/snapraid.content
|
|
|
|
|
|
:content /mnt/disk1/snapraid.content
|
|
|
|
|
|
:content /mnt/disk2/snapraid.content
|
|
|
|
|
|
:data d1 /mnt/disk1/
|
|
|
|
|
|
:data d2 /mnt/disk2/
|
|
|
|
|
|
:data d3 /mnt/disk3/
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви працюєте в Windows, ви повинні використовувати формат
|
|
|
|
|
|
шляху Windows, з літерами дисків та зворотними скісними рисками
|
|
|
|
|
|
замість прямих.
|
|
|
|
|
|
|
|
|
|
|
|
:parity E:\snapraid.parity
|
|
|
|
|
|
:content C:\snapraid\snapraid.content
|
|
|
|
|
|
:content F:\array\snapraid.content
|
|
|
|
|
|
:content G:\array\snapraid.content
|
|
|
|
|
|
:data d1 F:\array\
|
|
|
|
|
|
:data d2 G:\array\
|
|
|
|
|
|
:data d3 H:\array\
|
|
|
|
|
|
|
|
|
|
|
|
Якщо у вас багато дисків і закінчилися літери дисків, ви можете
|
|
|
|
|
|
монтувати диски безпосередньо у вкладені папки. Див:
|
|
|
|
|
|
|
|
|
|
|
|
:https://www.google.com/search?q=Windows+mount+point
|
|
|
|
|
|
|
|
|
|
|
|
На цьому етапі ви готові запустити команду `sync` для побудови
|
|
|
|
|
|
інформації парності.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid sync
|
|
|
|
|
|
|
|
|
|
|
|
Цей процес може зайняти кілька годин вперше, залежно від розміру
|
|
|
|
|
|
даних, які вже є на дисках. Якщо диски порожні, процес
|
|
|
|
|
|
відбувається миттєво.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете зупинити його в будь-який час, натиснувши Ctrl+C,
|
|
|
|
|
|
і під час наступного запуску він відновить роботу з місця,
|
|
|
|
|
|
де був перерваний.
|
|
|
|
|
|
|
|
|
|
|
|
Коли ця команда завершиться, ваші дані БЕЗПЕЧНІ.
|
|
|
|
|
|
|
|
|
|
|
|
Тепер ви можете почати використовувати свій масив як вам подобається
|
|
|
|
|
|
і періодично оновлювати інформацію парності, запускаючи команду `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
Скрабування (Scrubbing)
|
|
|
|
|
|
Щоб періодично перевіряти дані та парність на наявність помилок,
|
|
|
|
|
|
ви можете запустити команду `scrub`.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid scrub
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда порівнює дані у вашому масиві з хешем, обчисленим
|
|
|
|
|
|
під час команди `sync`, для перевірки цілісності.
|
|
|
|
|
|
|
|
|
|
|
|
Кожен запуск команди перевіряє приблизно 8% масиву, виключаючи
|
|
|
|
|
|
дані, які вже були скрабовані протягом попередніх 10 днів.
|
|
|
|
|
|
Ви можете використовувати опцію -p, --plan, щоб вказати іншу
|
|
|
|
|
|
кількість, і опцію -o, --older-than, щоб вказати інший вік
|
|
|
|
|
|
у днях.
|
|
|
|
|
|
Наприклад, щоб перевірити 5% масиву на блоки старші за 20 днів,
|
|
|
|
|
|
використовуйте:
|
|
|
|
|
|
|
2026-01-26 16:46:02 +01:00
|
|
|
|
:snapraid -p 5 -o 20 scrub
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Якщо під час процесу виявлено приховані помилки або помилки
|
|
|
|
|
|
введення/виведення, відповідні блоки позначаються як погані у
|
|
|
|
|
|
файлі `content` і перераховуються у команді `status`.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid status
|
|
|
|
|
|
|
|
|
|
|
|
Щоб їх виправити, ви можете використовувати команду `fix`,
|
|
|
|
|
|
фільтруючи погані блоки за допомогою опції -e, --filter-error:
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid -e fix
|
|
|
|
|
|
|
|
|
|
|
|
Під час наступного `scrub` помилки зникнуть зі звіту `status`,
|
|
|
|
|
|
якщо вони справді виправлені. Щоб зробити це швидше, ви можете
|
|
|
|
|
|
використовувати -p bad, щоб скрабувати лише блоки, позначені
|
|
|
|
|
|
як погані.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid -p bad scrub
|
|
|
|
|
|
|
|
|
|
|
|
Запуск `scrub` на несинхронізованому масиві може повідомити
|
|
|
|
|
|
про помилки, спричинені видаленими або зміненими файлами.
|
|
|
|
|
|
Ці помилки відображаються у виведенні `scrub`, але пов'язані
|
|
|
|
|
|
блоки не позначаються як погані.
|
|
|
|
|
|
|
|
|
|
|
|
Об'єднання (Pooling)
|
|
|
|
|
|
Примітка: Функція об'єднання, описана нижче, була замінена
|
2026-02-19 18:35:36 +01:00
|
|
|
|
інструментом mergerfs, який тепер є рекомендованою опцією для
|
2026-06-25 23:08:58 +02:00
|
|
|
|
користувачів Linux у спільноті SnapRAID. Mergerfs забезпечує
|
2025-12-13 19:34:07 +01:00
|
|
|
|
більш гнучкий та ефективний спосіб об'єднання кількох дисків
|
|
|
|
|
|
в єдину уніфіковану точку монтування, дозволяючи безперешкодний
|
|
|
|
|
|
доступ до файлів у вашому масиві без використання символічних
|
|
|
|
|
|
посилань. Він добре інтегрується з SnapRAID для захисту
|
|
|
|
|
|
парності і зазвичай використовується в налаштуваннях, таких
|
|
|
|
|
|
як OpenMediaVault (OMV) або користувацьких конфігураціях NAS.
|
2026-01-26 16:46:02 +01:00
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Щоб відобразити всі файли у вашому масиві в одному дереві
|
|
|
|
|
|
каталогів, ви можете ввімкнути функцію `pooling` (об'єднання).
|
|
|
|
|
|
Вона створює віртуальне представлення всіх файлів у вашому
|
|
|
|
|
|
масиві лише для читання, використовуючи символічні посилання.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете налаштувати каталог `pooling` у конфігураційному
|
|
|
|
|
|
файлі за допомогою:
|
|
|
|
|
|
|
|
|
|
|
|
:pool /pool
|
|
|
|
|
|
|
|
|
|
|
|
або, якщо ви працюєте в Windows, за допомогою:
|
|
|
|
|
|
|
|
|
|
|
|
:pool C:\pool
|
|
|
|
|
|
|
|
|
|
|
|
а потім запустити команду `pool` для створення або оновлення
|
|
|
|
|
|
віртуального представлення.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid pool
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви використовуєте платформу Unix і хочете надати спільний
|
|
|
|
|
|
доступ до цього каталогу через мережу для машин Windows або
|
|
|
|
|
|
Unix, ви повинні додати наступні опції до вашого
|
|
|
|
|
|
/etc/samba/smb.conf:
|
|
|
|
|
|
|
|
|
|
|
|
:# У глобальному розділі smb.conf
|
|
|
|
|
|
:unix extensions = no
|
|
|
|
|
|
|
|
|
|
|
|
:# У розділі спільного доступу smb.conf
|
|
|
|
|
|
:[pool]
|
|
|
|
|
|
:comment = Pool
|
|
|
|
|
|
:path = /pool
|
|
|
|
|
|
:read only = yes
|
|
|
|
|
|
:guest ok = yes
|
|
|
|
|
|
:wide links = yes
|
|
|
|
|
|
:follow symlinks = yes
|
|
|
|
|
|
|
|
|
|
|
|
У Windows спільний доступ до символічних посилань через мережу
|
|
|
|
|
|
вимагає від клієнтів віддаленого їх розпізнавання. Щоб
|
|
|
|
|
|
увімкнути це, окрім спільного доступу до каталогу pool, ви
|
|
|
|
|
|
також повинні надати спільний доступ до всіх дисків незалежно,
|
|
|
|
|
|
використовуючи імена дисків, визначені у конфігураційному
|
|
|
|
|
|
файлі, як точки спільного доступу. Ви також повинні вказати у
|
|
|
|
|
|
опції `share` конфігураційного файлу шлях Windows UNC, який
|
|
|
|
|
|
потрібен віддаленим клієнтам для доступу до цих спільних дисків.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, працюючи з сервера з іменем `darkstar`, ви можете
|
|
|
|
|
|
використовувати опції:
|
|
|
|
|
|
|
|
|
|
|
|
:data d1 F:\array\
|
|
|
|
|
|
:data d2 G:\array\
|
|
|
|
|
|
:data d3 H:\array\
|
|
|
|
|
|
:pool C:\pool
|
|
|
|
|
|
:share \\darkstar
|
|
|
|
|
|
|
|
|
|
|
|
і надати спільний доступ до наступних каталогів через мережу:
|
|
|
|
|
|
|
|
|
|
|
|
:\\darkstar\pool -> C:\pool
|
|
|
|
|
|
:\\darkstar\d1 -> F:\array
|
|
|
|
|
|
:\\darkstar\d2 -> G:\array
|
|
|
|
|
|
:\\darkstar\d3 -> H:\array
|
|
|
|
|
|
|
|
|
|
|
|
щоб дозволити віддаленим клієнтам отримати доступ до всіх файлів
|
|
|
|
|
|
за адресою \\darkstar\pool.
|
|
|
|
|
|
|
|
|
|
|
|
Вам також може знадобитися налаштувати віддалені клієнти, щоб
|
|
|
|
|
|
увімкнути доступ до віддалених символічних посилань за допомогою
|
|
|
|
|
|
команди:
|
|
|
|
|
|
|
|
|
|
|
|
:fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
|
|
|
|
|
|
|
|
|
|
|
|
Відновлення видалених файлів (Undeleting)
|
|
|
|
|
|
SnapRAID функціонує більше як програма резервного копіювання,
|
|
|
|
|
|
ніж система RAID, і його можна використовувати для відновлення
|
|
|
|
|
|
або повернення файлів до їх попереднього стану за допомогою
|
|
|
|
|
|
опції -f, --filter:
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid fix -f FILE
|
|
|
|
|
|
|
|
|
|
|
|
або для каталогу:
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid fix -f DIR/
|
|
|
|
|
|
|
|
|
|
|
|
Ви також можете використовувати його для відновлення лише випадково
|
|
|
|
|
|
видалених файлів усередині каталогу за допомогою опції -m,
|
|
|
|
|
|
--filter-missing, яка відновлює лише відсутні файли,
|
|
|
|
|
|
залишаючи всі інші недоторканими.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid fix -m -f DIR/
|
|
|
|
|
|
|
|
|
|
|
|
Або для відновлення всіх видалених файлів на всіх дисках за допомогою:
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid fix -m
|
|
|
|
|
|
|
|
|
|
|
|
Відновлення (Recovering)
|
|
|
|
|
|
Сталося найгірше, і ви втратили один або кілька дисків!
|
|
|
|
|
|
|
|
|
|
|
|
НЕ ПАНІКУЙТЕ! Ви зможете їх відновити!
|
|
|
|
|
|
|
|
|
|
|
|
Перше, що ви повинні зробити, це уникнути подальших змін у
|
|
|
|
|
|
вашому дисковому масиві. Вимкніть будь-які віддалені
|
|
|
|
|
|
підключення до нього та будь-які заплановані процеси,
|
|
|
|
|
|
включаючи будь-яку заплановану нічну синхронізацію або
|
|
|
|
|
|
скрабування SnapRAID.
|
|
|
|
|
|
|
|
|
|
|
|
Потім виконайте наступні кроки.
|
|
|
|
|
|
|
|
|
|
|
|
КРОК 1 -> Переналаштування
|
|
|
|
|
|
Вам потрібен деякий простір для відновлення, в ідеалі на
|
|
|
|
|
|
додаткових запасних дисках, але зовнішній USB-диск або
|
|
|
|
|
|
віддалений диск підійде.
|
|
|
|
|
|
|
|
|
|
|
|
Змініть конфігураційний файл SnapRAID, щоб опція `data` або
|
|
|
|
|
|
`parity` диска, що вийшов з ладу, вказувала на місце розташування
|
|
|
|
|
|
з достатньою кількістю вільного місця для відновлення файлів.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, якщо диск `d1` вийшов з ладу, змініть з:
|
|
|
|
|
|
|
|
|
|
|
|
:data d1 /mnt/disk1/
|
|
|
|
|
|
|
|
|
|
|
|
на:
|
|
|
|
|
|
|
|
|
|
|
|
:data d1 /mnt/new_spare_disk/
|
|
|
|
|
|
|
|
|
|
|
|
Якщо диск, який потрібно відновити, є диском парності, оновіть
|
|
|
|
|
|
відповідну опцію `parity`.
|
|
|
|
|
|
Якщо у вас кілька дисків, що вийшли з ладу, оновіть усі їхні
|
|
|
|
|
|
конфігураційні опції.
|
|
|
|
|
|
|
|
|
|
|
|
КРОК 2 -> Виправлення (Fix)
|
|
|
|
|
|
Запустіть команду fix, зберігаючи журнал у зовнішньому файлі
|
|
|
|
|
|
за допомогою:
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid -d NAME -l fix.log fix
|
|
|
|
|
|
|
|
|
|
|
|
Де NAME — це ім'я диска, наприклад `d1` у нашому попередньому
|
|
|
|
|
|
прикладі.
|
|
|
|
|
|
Якщо диск, який потрібно відновити, є диском парності,
|
|
|
|
|
|
використовуйте імена `parity`, `2-parity`, тощо.
|
|
|
|
|
|
Якщо у вас кілька дисків, що вийшли з ладу, використовуйте
|
|
|
|
|
|
кілька опцій -d, щоб вказати їх усі.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда займе багато часу.
|
|
|
|
|
|
|
|
|
|
|
|
Переконайтеся, що у вас є кілька гігабайт вільного місця для
|
|
|
|
|
|
зберігання файлу fix.log.
|
|
|
|
|
|
Запустіть її з диска з достатньою кількістю вільного місця.
|
|
|
|
|
|
|
|
|
|
|
|
Тепер ви відновили все, що можна відновити. Якщо деякі файли
|
|
|
|
|
|
частково або повністю неможливо відновити, вони будуть перейменовані
|
|
|
|
|
|
з додаванням розширення `.unrecoverable`.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете знайти детальний список усіх невідновлюваних блоків
|
|
|
|
|
|
у файлі fix.log, перевіривши всі рядки, що починаються з
|
|
|
|
|
|
`unrecoverable:`.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви не задоволені відновленням, ви можете повторити його
|
|
|
|
|
|
стільки разів, скільки забажаєте.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, якщо ви видалили файли з масиву після останньої
|
|
|
|
|
|
`sync`, це може призвести до того, що деякі файли не будуть
|
|
|
|
|
|
відновлені.
|
|
|
|
|
|
У цьому випадку ви можете повторити `fix`, використовуючи
|
|
|
|
|
|
опцію -i, --import, вказавши, де ці файли знаходяться зараз,
|
|
|
|
|
|
щоб знову включити їх у процес відновлення.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви задоволені відновленням, ви можете продовжити, але
|
|
|
|
|
|
зауважте, що після синхронізації ви більше не зможете повторити
|
|
|
|
|
|
команду `fix`!
|
|
|
|
|
|
|
|
|
|
|
|
КРОК 3 -> Перевірка (Check)
|
|
|
|
|
|
Як обережну перевірку, ви можете тепер запустити команду
|
|
|
|
|
|
`check`, щоб переконатися, що на відновленому диску все
|
|
|
|
|
|
правильно.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid -d NAME -a check
|
|
|
|
|
|
|
|
|
|
|
|
Де NAME — це ім'я диска, наприклад `d1` у нашому попередньому
|
|
|
|
|
|
прикладі.
|
|
|
|
|
|
|
|
|
|
|
|
Опції -d та -a вказують SnapRAID перевіряти лише вказаний
|
|
|
|
|
|
диск та ігнорувати всі дані парності.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда займе багато часу, але якщо ви не надто обережні,
|
|
|
|
|
|
ви можете її пропустити.
|
|
|
|
|
|
|
|
|
|
|
|
КРОК 4 -> Синхронізація (Sync)
|
|
|
|
|
|
Запустіть команду `sync`, щоб повторно синхронізувати масив
|
|
|
|
|
|
з новим диском.
|
|
|
|
|
|
|
|
|
|
|
|
:snapraid sync
|
|
|
|
|
|
|
|
|
|
|
|
Якщо все відновлено, ця команда виконується миттєво.
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Команди (Commands)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
SnapRAID надає кілька простих команд, які дозволяють:
|
|
|
|
|
|
|
|
|
|
|
|
* Вивести статус масиву -> `status`
|
|
|
|
|
|
* Керувати дисками -> `smart`, `probe`, `up`, `down`
|
2026-06-08 18:26:17 +02:00
|
|
|
|
* Створити точку резервного копіювання/відновлення -> `sync`
|
2025-12-13 19:34:07 +01:00
|
|
|
|
* Періодично перевіряти дані -> `scrub`
|
2026-06-08 18:26:17 +02:00
|
|
|
|
* Відновити останню точку резервного копіювання/відновлення -> `fix`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Команди обов'язково повинні бути написані малими літерами.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
status
|
|
|
|
|
|
Виводить зведення стану дискового масиву.
|
|
|
|
|
|
|
|
|
|
|
|
Включає інформацію про фрагментацію парності, вік блоків без
|
|
|
|
|
|
перевірки та всі записані приховані помилки, виявлені під
|
|
|
|
|
|
час скрабування.
|
|
|
|
|
|
|
|
|
|
|
|
Представлена інформація стосується останнього часу, коли ви
|
|
|
|
|
|
запустили `sync`. Пізніші модифікації не враховуються.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо виявлено погані блоки, перераховуються їхні номери блоків.
|
|
|
|
|
|
Щоб їх виправити, ви можете використовувати команду `fix -e`.
|
|
|
|
|
|
|
|
|
|
|
|
Також показує графік, що представляє останній час, коли
|
|
|
|
|
|
кожен блок був скрабований або синхронізований. Скрабовані
|
2026-02-14 11:07:51 +01:00
|
|
|
|
блоки позначаються символом `*`, блоки, синхронізовані,
|
|
|
|
|
|
але ще не скрабовані, - `o`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
smart
|
|
|
|
|
|
Виводить звіт SMART усіх дисків у системі.
|
|
|
|
|
|
|
|
|
|
|
|
Включає оцінку ймовірності відмови протягом наступного року,
|
2026-06-25 23:08:58 +02:00
|
|
|
|
дозволяючи вам планувати своєчасну заміну дисків, які
|
2025-12-13 19:34:07 +01:00
|
|
|
|
виявляють підозрілі атрибути.
|
|
|
|
|
|
|
|
|
|
|
|
Ця оцінка ймовірності отримана шляхом кореляції атрибутів
|
|
|
|
|
|
SMART дисків з даними Backblaze, доступними за адресою:
|
|
|
|
|
|
|
|
|
|
|
|
:https://www.backblaze.com/hard-drive-test-data.html
|
|
|
|
|
|
|
|
|
|
|
|
Якщо SMART повідомляє, що диск виходить з ладу, для цього
|
|
|
|
|
|
диска виводиться `FAIL` або `PREFAIL`, і SnapRAID повертає
|
2026-06-25 23:08:58 +02:00
|
|
|
|
помилку. У цьому випадку наполегливо рекомендується негайна
|
2025-12-13 19:34:07 +01:00
|
|
|
|
заміна диска.
|
|
|
|
|
|
|
|
|
|
|
|
Інші можливі рядки стану:
|
|
|
|
|
|
logfail - У минулому деякі атрибути були нижчими за
|
|
|
|
|
|
поріг.
|
|
|
|
|
|
logerr - Журнал помилок пристрою містить помилки.
|
|
|
|
|
|
selferr - Журнал самотестування пристрою містить помилки.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо вказано опцію -v, --verbose, надається глибший
|
|
|
|
|
|
статистичний аналіз. Цей аналіз може допомогти вам вирішити,
|
|
|
|
|
|
чи потрібна вам більша або менша парність.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда використовує інструмент `smartctl` і еквівалентна
|
|
|
|
|
|
запуску `smartctl -a` на всіх пристроях.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ваші пристрої не виявляються автоматично правильно, ви
|
|
|
|
|
|
можете вказати користувацьку команду, використовуючи опцію
|
|
|
|
|
|
`smartctl` у конфігураційному файлі.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
probe
|
|
|
|
|
|
Виводить стан ЖИВЛЕННЯ всіх дисків у системі.
|
|
|
|
|
|
|
|
|
|
|
|
`Standby` означає, що диск не обертається. `Active` означає,
|
|
|
|
|
|
що диск обертається.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда використовує інструмент `smartctl` і еквівалентна
|
|
|
|
|
|
запуску `smartctl -n standby -i` на всіх пристроях.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ваші пристрої не виявляються автоматично правильно, ви
|
|
|
|
|
|
можете вказати користувацьку команду, використовуючи опцію
|
|
|
|
|
|
`smartctl` у конфігураційному файлі.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
up
|
|
|
|
|
|
Розкручує всі диски масиву.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете розкрутити лише певні диски, використовуючи
|
|
|
|
|
|
опцію -d, --filter-disk.
|
|
|
|
|
|
|
|
|
|
|
|
Одночасне розкручування всіх дисків вимагає багато енергії.
|
|
|
|
|
|
Переконайтеся, що ваш блок живлення може це витримати.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
down
|
|
|
|
|
|
Зупиняє всі диски масиву.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда використовує інструмент `smartctl` і еквівалентна
|
|
|
|
|
|
запуску `smartctl -s standby,now` на всіх пристроях.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете зупинити лише певні диски, використовуючи
|
|
|
|
|
|
опцію -d, --filter-disk.
|
|
|
|
|
|
|
|
|
|
|
|
Для автоматичної зупинки при помилці ви можете
|
|
|
|
|
|
використовувати опцію -s, --spin-down-on-error з будь-якою
|
|
|
|
|
|
іншою командою, що еквівалентно ручному запуску `down`
|
|
|
|
|
|
при виникненні помилки.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
diff
|
|
|
|
|
|
Виводить список усіх файлів, змінених з моменту останньої
|
|
|
|
|
|
`sync`, для яких необхідно перерахувати дані парності.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда не перевіряє дані файлів, а лише часову мітку
|
|
|
|
|
|
файлу, розмір та inode.
|
|
|
|
|
|
|
|
|
|
|
|
Після перерахування всіх змінених файлів представляється
|
|
|
|
|
|
зведення змін, згруповане за:
|
|
|
|
|
|
equal (рівні) - Файли, незмінені з попереднього стану.
|
|
|
|
|
|
added (додані) - Файли, додані, яких не було раніше.
|
|
|
|
|
|
removed (видалені) - Файли, видалені.
|
|
|
|
|
|
updated (оновлені) - Файли з іншим розміром або часовою
|
|
|
|
|
|
міткою, що означає, що вони були змінені.
|
2026-09-09 10:13:19 +02:00
|
|
|
|
moved (переміщені) - Файли, переміщені або перейменовані на тому ж
|
|
|
|
|
|
диску зі збереженням того ж inode. Вони ідентифікуються за
|
|
|
|
|
|
тим самим inode, розміром і міткою часу, але іншим шляхом.
|
|
|
|
|
|
Назва файлу також може відрізнятися.
|
2026-06-25 23:08:58 +02:00
|
|
|
|
copied (скопійовані) - Файли, скопійовані на той самий або інший диск, де
|
2026-03-16 23:43:14 +01:00
|
|
|
|
оригінальний файл все ще існує.
|
|
|
|
|
|
Вони ідентифікуються за однаковою назвою, розміром та міткою
|
|
|
|
|
|
часу.
|
|
|
|
|
|
Якщо мітка часу з точністю до часток секунди дорівнює нулю, для
|
|
|
|
|
|
ідентифікації має збігатися повний шлях, а не лише назва.
|
2026-09-09 10:13:19 +02:00
|
|
|
|
relocated (перерозміщені) - Файли, переміщені в інший каталог або на
|
|
|
|
|
|
інший диск, де оригінальний файл зник, а inode не зберігся.
|
|
|
|
|
|
Вони ідентифікуються за однаковою назвою, розміром та міткою часу.
|
2026-03-16 23:43:14 +01:00
|
|
|
|
Якщо мітка часу з точністю до часток секунди дорівнює нулю, для
|
2026-09-09 10:13:19 +02:00
|
|
|
|
ідентифікації має збігатися повний шлях. На відміну від файлів
|
|
|
|
|
|
'moved', перерозміщені файли вимагають, щоб назва файлу залишалася
|
|
|
|
|
|
незмінною.
|
2026-06-25 23:08:58 +02:00
|
|
|
|
restored (відновлені) - Файли з іншим inode, але зі збігом каталогу, назви,
|
2026-03-16 23:43:14 +01:00
|
|
|
|
розміру та мітки часу.
|
|
|
|
|
|
Зазвичай це файли, відновлені після видалення.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Якщо потрібна `sync`, код повернення процесу дорівнює 2,
|
|
|
|
|
|
замість стандартного 0. Код повернення 1 використовується для
|
|
|
|
|
|
загальної умови помилки.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
sync
|
|
|
|
|
|
Оновлює інформацію парності. Всі змінені файли у дисковому
|
|
|
|
|
|
масиві зчитуються, і відповідні дані парності оновлюються.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете зупинити цей процес у будь-який час, натиснувши
|
|
|
|
|
|
Ctrl+C, не втрачаючи вже виконану роботу.
|
|
|
|
|
|
Під час наступного запуску процес `sync` відновить роботу
|
|
|
|
|
|
з місця, де був перерваний.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо під час процесу виявлено приховані помилки або помилки
|
|
|
|
|
|
введення/виведення, відповідні блоки позначаються як погані.
|
|
|
|
|
|
|
|
|
|
|
|
Файли ідентифікуються за шляхом та/або inode та перевіряються
|
|
|
|
|
|
за розміром та часовою міткою.
|
|
|
|
|
|
Якщо розмір або часова мітка файлу відрізняються, дані
|
|
|
|
|
|
парності перераховуються для всього файлу.
|
|
|
|
|
|
Якщо файл переміщено або перейменовано на тому ж диску,
|
|
|
|
|
|
зберігаючи той самий inode, парність не перераховується.
|
|
|
|
|
|
Якщо файл переміщено на інший диск, парність перераховується,
|
|
|
|
|
|
але раніше обчислена інформація хешу зберігається.
|
|
|
|
|
|
|
|
|
|
|
|
Файли `content` та `parity` змінюються за потреби.
|
|
|
|
|
|
Файли в масиві НЕ змінюються.
|
|
|
|
|
|
|
|
|
|
|
|
scrub
|
|
|
|
|
|
Скрабує масив, перевіряючи на наявність прихованих помилок
|
|
|
|
|
|
або помилок введення/виведення на дисках даних та парності.
|
|
|
|
|
|
|
|
|
|
|
|
Кожен виклик перевіряє приблизно 8% масиву, виключаючи
|
|
|
|
|
|
дані, які вже були скрабовані протягом останніх 10 днів.
|
|
|
|
|
|
Це означає, що скрабування раз на тиждень забезпечує
|
|
|
|
|
|
перевірку кожного біта даних принаймні раз на три місяці.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете визначити інший план скрабування або кількість
|
|
|
|
|
|
за допомогою опції -p, --plan, яка приймає:
|
|
|
|
|
|
bad - Скрабувати блоки, позначені як погані.
|
|
|
|
|
|
new - Скрабувати щойно синхронізовані блоки, які ще не були
|
|
|
|
|
|
скрабовані.
|
|
|
|
|
|
full - Скрабувати все.
|
|
|
|
|
|
0-100 - Скрабувати вказаний відсоток блоків.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви вказуєте відсоткове значення, ви також можете
|
|
|
|
|
|
використовувати опцію -o, --older-than, щоб визначити,
|
|
|
|
|
|
яким має бути вік блоку.
|
|
|
|
|
|
Найстаріші блоки скрабуються першими, забезпечуючи оптимальну
|
|
|
|
|
|
перевірку.
|
|
|
|
|
|
Якщо ви хочете скрабувати лише щойно синхронізовані блоки,
|
|
|
|
|
|
які ще не були скрабовані, використовуйте опцію `-p new`.
|
|
|
|
|
|
|
|
|
|
|
|
Щоб отримати деталі статусу скрабування, використовуйте команду
|
|
|
|
|
|
`status`.
|
|
|
|
|
|
|
|
|
|
|
|
Для будь-якої знайденої прихованої помилки або помилки
|
|
|
|
|
|
введення/виведення відповідні блоки позначаються як погані
|
|
|
|
|
|
у файлі `content`.
|
|
|
|
|
|
Ці погані блоки перераховуються у `status` і можуть бути
|
|
|
|
|
|
виправлені за допомогою `fix -e`.
|
|
|
|
|
|
Після виправлення, під час наступного скрабування, вони будуть
|
|
|
|
|
|
повторно перевірені, і якщо виявиться, що вони виправлені,
|
|
|
|
|
|
позначка "поганий" буде видалена.
|
|
|
|
|
|
Щоб скрабувати лише погані блоки, ви можете використовувати
|
|
|
|
|
|
команду `scrub -p bad`.
|
|
|
|
|
|
|
|
|
|
|
|
Рекомендується запускати `scrub` лише на синхронізованому
|
|
|
|
|
|
масиві, щоб уникнути повідомлень про помилки, спричинені
|
|
|
|
|
|
несинхронізованими даними. Ці помилки розпізнаються як
|
|
|
|
|
|
не приховані помилки, і блоки не позначаються як погані,
|
|
|
|
|
|
але такі помилки повідомляються у виведенні команди.
|
|
|
|
|
|
|
|
|
|
|
|
Файл `content` змінюється для оновлення часу останньої перевірки
|
|
|
|
|
|
для кожного блоку та для позначення поганих блоків.
|
|
|
|
|
|
Файли `parity` НЕ змінюються.
|
|
|
|
|
|
Файли в масиві НЕ змінюються.
|
|
|
|
|
|
|
|
|
|
|
|
fix
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Відновлює всі файли та дані парності.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Усі файли та дані парності порівнюються зі станом, збереженим під час
|
|
|
|
|
|
останньої синхронізації `sync`. Якщо виявлено відмінність, стан повертається до збереженого.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-08 18:26:17 +02:00
|
|
|
|
УВАГА!
|
|
|
|
|
|
Команда `fix` не робить різниці між помилками та навмисними змінами.
|
|
|
|
|
|
Вона безумовно повертає стан файлів до моменту останньої синхронізації `sync`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Якщо не вказано жодної іншої опції, обробляється весь масив.
|
|
|
|
|
|
Використовуйте опції фільтра, щоб вибрати підмножину файлів
|
|
|
|
|
|
або дисків для роботи.
|
|
|
|
|
|
|
|
|
|
|
|
Щоб виправити лише блоки, позначені як погані під час `sync`
|
|
|
|
|
|
та `scrub`, використовуйте опцію -e, --filter-error.
|
|
|
|
|
|
На відміну від інших опцій фільтра, ця застосовує виправлення
|
|
|
|
|
|
лише до файлів, які не змінилися з моменту останньої `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
SnapRAID перейменовує всі файли, які не можуть бути виправлені,
|
|
|
|
|
|
додаючи розширення `.unrecoverable`.
|
|
|
|
|
|
|
|
|
|
|
|
Перед виправленням сканується весь масив, щоб знайти будь-які
|
|
|
|
|
|
файли, переміщені з моменту останньої `sync`.
|
|
|
|
|
|
Ці файли ідентифікуються за їхньою часовою міткою, ігноруючи
|
|
|
|
|
|
їхнє ім'я та каталог, і використовуються в процесі відновлення,
|
|
|
|
|
|
якщо це необхідно.
|
|
|
|
|
|
Якщо ви перемістили деякі з них за межі масиву, ви можете
|
|
|
|
|
|
використовувати опцію -i, --import, щоб вказати додаткові
|
|
|
|
|
|
каталоги для сканування.
|
|
|
|
|
|
|
|
|
|
|
|
Файли ідентифікуються лише за шляхом, а не за inode.
|
|
|
|
|
|
|
|
|
|
|
|
Файл `content` НЕ змінюється.
|
|
|
|
|
|
Файли `parity` змінюються за потреби.
|
|
|
|
|
|
Файли в масиві змінюються за потреби.
|
|
|
|
|
|
|
|
|
|
|
|
check
|
|
|
|
|
|
Перевіряє всі файли та дані парності.
|
|
|
|
|
|
|
|
|
|
|
|
Працює як `fix`, але лише імітує відновлення, і жодні зміни
|
|
|
|
|
|
не записуються в масив.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Ця команда насамперед призначена для ручної перевірки,
|
2025-12-13 19:34:07 +01:00
|
|
|
|
наприклад, після процесу відновлення або в інших особливих
|
|
|
|
|
|
умовах. Для періодичних та запланованих перевірок використовуйте
|
|
|
|
|
|
`scrub`.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви використовуєте опцію -a, --audit-only, перевіряється
|
|
|
|
|
|
лише хеш файлів, а дані парності ігноруються для швидшого
|
|
|
|
|
|
запуску.
|
|
|
|
|
|
|
|
|
|
|
|
Файли ідентифікуються лише за шляхом, а не за inode.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
list
|
|
|
|
|
|
Виводить список усіх файлів, що містяться в масиві на момент
|
|
|
|
|
|
останньої `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
З -v або --verbose також показується час з точністю до
|
2026-06-25 23:08:58 +02:00
|
|
|
|
часток секунди.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
dup
|
|
|
|
|
|
Виводить список усіх дублікатів файлів. Два файли вважаються
|
|
|
|
|
|
рівними, якщо їхні хеші збігаються. Дані файлів не
|
|
|
|
|
|
зчитуються; використовуються лише попередньо обчислені хеші.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
pool
|
|
|
|
|
|
Створює або оновлює віртуальне представлення всіх файлів
|
|
|
|
|
|
у вашому дисковому масиві в каталозі `pooling`.
|
|
|
|
|
|
|
|
|
|
|
|
Файли не копіюються, а пов'язуються за допомогою символічних
|
|
|
|
|
|
посилань.
|
|
|
|
|
|
|
|
|
|
|
|
Під час оновлення всі існуючі символічні посилання та порожні
|
|
|
|
|
|
підкаталоги видаляються та замінюються новим
|
|
|
|
|
|
представленням масиву. Будь-які інші звичайні файли залишаються
|
|
|
|
|
|
на місці.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється за межами каталогу pool.
|
|
|
|
|
|
|
|
|
|
|
|
devices
|
|
|
|
|
|
Виводить низькорівневі пристрої, які використовуються масивом.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда відображає асоціації пристроїв у масиві і в
|
|
|
|
|
|
основному призначена як інтерфейс для сценаріїв.
|
|
|
|
|
|
|
|
|
|
|
|
Перші два стовпці — це низькорівневий ідентифікатор пристрою
|
|
|
|
|
|
та шлях.
|
|
|
|
|
|
Наступні два стовпці — це високорівневий ідентифікатор пристрою
|
|
|
|
|
|
та шлях.
|
|
|
|
|
|
Останній стовпець — це ім'я диска в масиві.
|
|
|
|
|
|
|
|
|
|
|
|
У більшості випадків у вас є один низькорівневий пристрій для
|
|
|
|
|
|
кожного диска в масиві, але в деяких складніших конфігураціях
|
|
|
|
|
|
у вас може бути кілька низькорівневих пристроїв, які використовуються
|
|
|
|
|
|
одним диском у масиві.
|
|
|
|
|
|
|
|
|
|
|
|
Нічого не змінюється.
|
|
|
|
|
|
|
|
|
|
|
|
touch
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Встановлює довільну часову мітку з точністю до часток секунди
|
2025-12-13 19:34:07 +01:00
|
|
|
|
для всіх файлів, у яких вона встановлена на нуль.
|
|
|
|
|
|
|
|
|
|
|
|
Це покращує здатність SnapRAID розпізнавати переміщені та
|
|
|
|
|
|
скопійовані файли, оскільки робить часову мітку майже
|
|
|
|
|
|
унікальною, зменшуючи можливі дублікати.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Зокрема, якщо часова мітка з точністю до часток секунди не
|
2025-12-13 19:34:07 +01:00
|
|
|
|
дорівнює нулю, переміщений або скопійований файл ідентифікується
|
|
|
|
|
|
як такий, якщо він збігається з іменем, розміром та часовою
|
2026-06-25 23:08:58 +02:00
|
|
|
|
міткою. Якщо часова мітка з точністю до часток секунди дорівнює
|
2025-12-13 19:34:07 +01:00
|
|
|
|
нулю, він вважається копією, лише якщо повний шлях, розмір та
|
|
|
|
|
|
часова мітка збігаються.
|
|
|
|
|
|
|
|
|
|
|
|
Часова мітка з точністю до секунди не змінюється, тому
|
|
|
|
|
|
всі дати та час ваших файлів будуть збережені.
|
|
|
|
|
|
|
|
|
|
|
|
rehash
|
|
|
|
|
|
Планує повторне хешування всього масиву.
|
|
|
|
|
|
|
|
|
|
|
|
Ця команда змінює тип хешу, що використовується, як правило,
|
|
|
|
|
|
при оновленні з 32-розрядної системи на 64-розрядну, щоб
|
|
|
|
|
|
переключитися з MurmurHash3 на швидший SpookyHash.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви вже використовуєте оптимальний хеш, ця команда
|
|
|
|
|
|
нічого не робить і повідомляє, що жодних дій не потрібно.
|
|
|
|
|
|
|
|
|
|
|
|
Повторне хешування не виконується негайно, а відбувається
|
|
|
|
|
|
поступово під час `sync` та `scrub`.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете перевірити стан повторного хешування за допомогою
|
|
|
|
|
|
`status`.
|
|
|
|
|
|
|
|
|
|
|
|
Під час повторного хешування SnapRAID зберігає повну
|
|
|
|
|
|
функціональність, за єдиним винятком, що `dup` не може
|
|
|
|
|
|
виявити дублікати файлів, використовуючи інший хеш.
|
|
|
|
|
|
|
2026-02-25 14:48:54 +01:00
|
|
|
|
locate
|
|
|
|
|
|
Знаходить файли, що зберігаються на дисках парності. Для кожного знайденого
|
|
|
|
|
|
файлу виводиться його розташування всередині файлу парності та кількість
|
|
|
|
|
|
фрагментів, які він займає.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете використовувати параметр -t, --tail, щоб обмежити операцію файлами,
|
|
|
|
|
|
що займають зазначену кінцеву частину (хвіст) парності.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ви хочете перерозподілити ці файли, ви можете скористатися параметром
|
|
|
|
|
|
-W, --force-realloc-tail.
|
|
|
|
|
|
Майте на увазі, що такі файли не будуть захищені парністю під час процесу
|
|
|
|
|
|
перерозподілу.
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Опції (Options)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
SnapRAID надає наступні опції:
|
|
|
|
|
|
|
|
|
|
|
|
-c, --conf CONFIG
|
|
|
|
|
|
Вибирає конфігураційний файл для використання. Якщо не
|
|
|
|
|
|
вказано, в Unix використовується файл `/usr/local/etc/snapraid.conf`,
|
|
|
|
|
|
якщо він існує, інакше `/etc/snapraid.conf`.
|
|
|
|
|
|
У Windows використовується файл `snapraid.conf` у тому
|
|
|
|
|
|
самому каталозі, що й `snapraid.exe`.
|
|
|
|
|
|
|
|
|
|
|
|
-f, --filter PATTERN
|
|
|
|
|
|
Фільтрує файли для обробки у `check` та `fix`.
|
|
|
|
|
|
Обробляються лише файли, що відповідають вказаному
|
|
|
|
|
|
шаблону. Цю опцію можна використовувати кілька разів.
|
|
|
|
|
|
Дивіться розділ PATTERN для отримання додаткової
|
|
|
|
|
|
інформації про специфікації шаблонів.
|
2026-06-25 23:08:58 +02:00
|
|
|
|
В Unix переконайтеся, що символи глобінгу взяті
|
2025-12-13 19:34:07 +01:00
|
|
|
|
в лапки, якщо вони використовуються.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check` та `fix`.
|
|
|
|
|
|
Її не можна використовувати з `sync` та `scrub`, оскільки
|
|
|
|
|
|
вони завжди обробляють весь масив.
|
|
|
|
|
|
|
|
|
|
|
|
-d, --filter-disk NAME
|
|
|
|
|
|
Фільтрує диски для обробки у `check`, `fix`, `up` та `down`.
|
|
|
|
|
|
Ви повинні вказати ім'я диска, як визначено у
|
|
|
|
|
|
конфігураційному файлі.
|
|
|
|
|
|
Ви також можете вказати диски парності з іменами:
|
|
|
|
|
|
`parity`, `2-parity`, `3-parity`, тощо, щоб обмежити
|
|
|
|
|
|
операції певним диском парності.
|
|
|
|
|
|
Якщо ви поєднуєте кілька опцій --filter, --filter-disk
|
|
|
|
|
|
та --filter-missing, вибираються лише файли, що
|
|
|
|
|
|
відповідають усім фільтрам.
|
|
|
|
|
|
Цю опцію можна використовувати кілька разів.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check`, `fix`,
|
|
|
|
|
|
`up` та `down`.
|
|
|
|
|
|
Її не можна використовувати з `sync` та `scrub`, оскільки
|
|
|
|
|
|
вони завжди обробляють весь масив.
|
|
|
|
|
|
|
|
|
|
|
|
-m, --filter-missing
|
|
|
|
|
|
Фільтрує файли для обробки у `check` та `fix`.
|
|
|
|
|
|
Обробляються лише файли, що відсутні або видалені з
|
|
|
|
|
|
масиву. При використанні з `fix` це діє як команда
|
|
|
|
|
|
`undelete` (відновлення видалених файлів).
|
|
|
|
|
|
Якщо ви поєднуєте кілька опцій --filter, --filter-disk
|
|
|
|
|
|
та --filter-missing, вибираються лише файли, що
|
|
|
|
|
|
відповідають усім фільтрам.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check` та `fix`.
|
|
|
|
|
|
Її не можна використовувати з `sync` та `scrub`, оскільки
|
|
|
|
|
|
вони завжди обробляють весь масив.
|
|
|
|
|
|
|
|
|
|
|
|
-e, --filter-error
|
|
|
|
|
|
Обробляє файли з помилками у `check` та `fix`.
|
|
|
|
|
|
Обробляє лише файли, які мають блоки, позначені
|
|
|
|
|
|
прихованими помилками або помилками введення/виведення
|
|
|
|
|
|
під час `sync` та `scrub`, як зазначено у `status`.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check` та `fix`.
|
|
|
|
|
|
|
|
|
|
|
|
-p, --plan PERC|bad|new|full
|
|
|
|
|
|
Вибирає план скрабування. Якщо PERC є числовим
|
|
|
|
|
|
значенням від 0 до 100, воно інтерпретується як відсоток
|
|
|
|
|
|
блоків для скрабування.
|
|
|
|
|
|
Замість відсотка ви можете вказати план: `bad`
|
|
|
|
|
|
скрабує погані блоки, `new` скрабує блоки, які ще не
|
|
|
|
|
|
були скрабовані, і `full` скрабує все.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `scrub`.
|
|
|
|
|
|
|
|
|
|
|
|
-o, --older-than DAYS
|
|
|
|
|
|
Вибирає найстарішу частину масиву для обробки у `scrub`.
|
|
|
|
|
|
DAYS — це мінімальний вік у днях для блоку, який
|
|
|
|
|
|
повинен бути скрабований; за замовчуванням 10.
|
|
|
|
|
|
Блоки, позначені як погані, завжди скрабуються
|
|
|
|
|
|
незалежно від цієї опції.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `scrub`.
|
|
|
|
|
|
|
|
|
|
|
|
-a, --audit-only
|
|
|
|
|
|
У `check` перевіряє хеш файлів без перевірки даних
|
|
|
|
|
|
парності. Якщо вас цікавить лише перевірка даних файлів,
|
|
|
|
|
|
ця опція може значно прискорити процес перевірки.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check`.
|
|
|
|
|
|
|
|
|
|
|
|
-h, --pre-hash
|
|
|
|
|
|
У `sync` запускає попередню фазу хешування всіх нових
|
|
|
|
|
|
даних для додаткової перевірки перед обчисленням
|
|
|
|
|
|
парності. Зазвичай у `sync` не виконується попереднє
|
|
|
|
|
|
хешування, а нові дані хешуються безпосередньо перед
|
|
|
|
|
|
обчисленням парності, коли вони зчитуються вперше.
|
|
|
|
|
|
Цей процес відбувається, коли система знаходиться під
|
|
|
|
|
|
великим навантаженням, усі диски обертаються та ЦП
|
|
|
|
|
|
зайнятий. Це екстремальна умова для машини, і якщо вона
|
|
|
|
|
|
має приховану апаратну проблему, приховані помилки
|
|
|
|
|
|
можуть залишитися невиявленими, оскільки дані ще не
|
|
|
|
|
|
були хешовані.
|
|
|
|
|
|
Щоб уникнути цього ризику, ви можете ввімкнути режим
|
|
|
|
|
|
`pre-hash`, щоб усі дані були зчитані двічі для
|
|
|
|
|
|
забезпечення їх цілісності.
|
|
|
|
|
|
Ця опція також перевіряє файли, переміщені в межах
|
|
|
|
|
|
масиву, щоб переконатися, що операція переміщення була
|
|
|
|
|
|
успішною, і, якщо необхідно, дозволяє запустити операцію
|
|
|
|
|
|
виправлення перед продовженням.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
-i, --import DIR
|
|
|
|
|
|
Імпортує з вказаного каталогу будь-які файли, видалені
|
|
|
|
|
|
з масиву після останньої `sync`.
|
|
|
|
|
|
Якщо у вас все ще є такі файли, вони можуть бути
|
|
|
|
|
|
використані `check` та `fix` для покращення процесу
|
|
|
|
|
|
відновлення.
|
|
|
|
|
|
Файли зчитуються, включаючи підкаталоги, та
|
|
|
|
|
|
ідентифікуються незалежно від їхнього імені.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `check` та `fix`.
|
|
|
|
|
|
|
|
|
|
|
|
-s, --spin-down-on-error
|
|
|
|
|
|
При будь-якій помилці зупиняє всі керовані диски перед
|
|
|
|
|
|
завершенням з ненульовим кодом стану. Це запобігає
|
|
|
|
|
|
тому, щоб диски залишалися активними та оберталися
|
|
|
|
|
|
після перерваної операції, допомагаючи уникнути
|
|
|
|
|
|
зайвого нагрівання та споживання електроенергії.
|
|
|
|
|
|
Використовуйте цю опцію, щоб забезпечити безпечну
|
|
|
|
|
|
зупинку дисків, навіть коли команда завершується
|
|
|
|
|
|
помилкою.
|
|
|
|
|
|
|
|
|
|
|
|
-w, --bw-limit RATE
|
|
|
|
|
|
Застосовує глобальне обмеження пропускної здатності
|
|
|
|
|
|
для всіх дисків. RATE — це кількість байтів на секунду.
|
|
|
|
|
|
Ви можете вказати множник, такий як K, M або G (наприклад,
|
|
|
|
|
|
--bw-limit 1G).
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
-t, --tail SIZE
|
2026-02-25 14:48:54 +01:00
|
|
|
|
Обмежує список файлів тими, що використовують не більше зазначеного
|
|
|
|
|
|
розміру хвоста дисків парності.
|
|
|
|
|
|
Можна використовувати множники, такі як K, M, G або T (наприклад, --tail 1G).
|
|
|
|
|
|
Цей параметр дійсний лише при використанні разом із командою `locate`.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
-A, --stats
|
|
|
|
|
|
Вмикає розширений перегляд стану, який показує
|
|
|
|
|
|
додаткову інформацію.
|
|
|
|
|
|
На екрані відображаються два графіки:
|
|
|
|
|
|
Перший графік показує кількість буферизованих смуг
|
|
|
|
|
|
(stripes) для кожного диска, разом зі шляхом до файлу,
|
|
|
|
|
|
до якого наразі здійснюється доступ на цьому диску.
|
|
|
|
|
|
Зазвичай найповільніший диск не матиме доступного
|
|
|
|
|
|
буфера, що визначає максимально досяжну пропускну
|
|
|
|
|
|
здатність.
|
|
|
|
|
|
Другий графік показує відсоток часу, витраченого на
|
|
|
|
|
|
очікування, за останні 100 секунд. Очікується, що
|
|
|
|
|
|
найповільніший диск спричинить більшу частину часу
|
|
|
|
|
|
очікування, тоді як інші диски повинні мати невеликий
|
|
|
|
|
|
час очікування або зовсім його не мати, оскільки
|
|
|
|
|
|
вони можуть використовувати свої буферизовані смуги.
|
|
|
|
|
|
Цей графік також показує час, витрачений на очікування
|
|
|
|
|
|
обчислення хешу та обчислень RAID.
|
|
|
|
|
|
Усі обчислення виконуються паралельно з операціями
|
|
|
|
|
|
диска. Тому, доки є вимірюваний час очікування
|
|
|
|
|
|
принаймні для одного диска, це вказує на те, що ЦП
|
|
|
|
|
|
достатньо швидкий, щоб справлятися з робочим навантаженням.
|
|
|
|
|
|
|
|
|
|
|
|
-Z, --force-zero
|
|
|
|
|
|
Форсує небезпечну операцію синхронізації файлу з
|
|
|
|
|
|
нульовим розміром, який раніше був ненульовим.
|
|
|
|
|
|
Якщо SnapRAID виявляє таку умову, він припиняє
|
|
|
|
|
|
продовження, якщо ви не вкажете цю опцію.
|
|
|
|
|
|
Це дозволяє легко виявити, коли після збою системи
|
|
|
|
|
|
деякі доступні файли були обрізані.
|
|
|
|
|
|
Це можлива умова в Linux з файловими системами
|
|
|
|
|
|
ext3/ext4.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
-E, --force-empty
|
|
|
|
|
|
Форсує небезпечну операцію синхронізації диска, на
|
|
|
|
|
|
якому відсутні всі оригінальні файли.
|
|
|
|
|
|
Якщо SnapRAID виявляє, що всі файли, які спочатку
|
|
|
|
|
|
були на диску, відсутні або перезаписані, він
|
|
|
|
|
|
припиняє продовження, якщо ви не вкажете цю опцію.
|
|
|
|
|
|
Це дозволяє легко виявити, коли файлова система
|
|
|
|
|
|
даних не змонтована.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
-U, --force-uuid
|
|
|
|
|
|
Форсує небезпечну операцію синхронізації, перевірки
|
|
|
|
|
|
та виправлення з дисками, які змінили свій UUID.
|
|
|
|
|
|
Якщо SnapRAID виявляє, що деякі диски змінили UUID,
|
|
|
|
|
|
він припиняє продовження, якщо ви не вкажете цю опцію.
|
|
|
|
|
|
Це дозволяє виявити, коли ваші диски змонтовані
|
|
|
|
|
|
в неправильних точках монтування.
|
|
|
|
|
|
Однак, дозволено мати одну зміну UUID з однією парністю
|
|
|
|
|
|
і більше з множинною парністю, оскільки це нормальний
|
|
|
|
|
|
випадок при заміні дисків після відновлення.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`, `check`
|
|
|
|
|
|
або `fix`.
|
|
|
|
|
|
|
|
|
|
|
|
-D, --force-device
|
|
|
|
|
|
Форсує небезпечну операцію виправлення з недоступними
|
|
|
|
|
|
дисками або з дисками на тому ж фізичному пристрої.
|
|
|
|
|
|
Наприклад, якщо ви втратили два диски даних і маєте
|
|
|
|
|
|
запасний диск для відновлення лише першого, ви можете
|
|
|
|
|
|
ігнорувати другий недоступний диск.
|
|
|
|
|
|
Або, якщо ви хочете відновити диск у вільному місці,
|
|
|
|
|
|
залишеному на вже використовуваному диску, що
|
|
|
|
|
|
використовує той самий фізичний пристрій.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `fix`.
|
|
|
|
|
|
|
|
|
|
|
|
-N, --force-nocopy
|
|
|
|
|
|
У `sync`, `check` та `fix` вимикає евристику
|
|
|
|
|
|
виявлення копій. Без цієї опції SnapRAID припускає,
|
|
|
|
|
|
що файли з однаковими атрибутами, такими як ім'я,
|
|
|
|
|
|
розмір та часова мітка, є копіями з тими ж даними.
|
|
|
|
|
|
Це дозволяє ідентифікувати скопійовані або
|
|
|
|
|
|
переміщені файли з одного диска на інший і повторно
|
|
|
|
|
|
використовує вже обчислену інформацію хешу для
|
|
|
|
|
|
виявлення прихованих помилок або для відновлення
|
|
|
|
|
|
відсутніх файлів.
|
|
|
|
|
|
У деяких рідкісних випадках ця поведінка може
|
|
|
|
|
|
призвести до хибних спрацьовувань або повільного
|
|
|
|
|
|
процесу через багато перевірок хешу, і ця опція
|
|
|
|
|
|
дозволяє вирішити такі проблеми.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`, `check`
|
|
|
|
|
|
та `fix`.
|
|
|
|
|
|
|
|
|
|
|
|
-F, --force-full
|
|
|
|
|
|
У `sync` форсує повне переобчислення парності.
|
|
|
|
|
|
Цю опцію можна використовувати, коли ви додаєте
|
|
|
|
|
|
новий рівень парності або якщо ви повернулися до
|
|
|
|
|
|
старого файлу вмісту, використовуючи більш
|
|
|
|
|
|
нові дані парності.
|
|
|
|
|
|
Замість створення парності з нуля, це дозволяє
|
|
|
|
|
|
повторно використовувати хеші, присутні у файлі
|
|
|
|
|
|
вмісту, для перевірки даних та підтримки захисту
|
|
|
|
|
|
даних під час процесу `sync`, використовуючи
|
|
|
|
|
|
існуючі дані парності.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
-R, --force-realloc
|
|
|
|
|
|
У `sync` форсує повне перерозподілення файлів
|
|
|
|
|
|
та перебудову парності.
|
|
|
|
|
|
Цю опцію можна використовувати для повного
|
|
|
|
|
|
перерозподілу всіх файлів, усуваючи фрагментацію,
|
|
|
|
|
|
повторно використовуючи хеші, присутні у файлі
|
|
|
|
|
|
вмісту, для перевірки даних.
|
|
|
|
|
|
Цю опцію можна використовувати лише з `sync`.
|
|
|
|
|
|
УВАГА! Ця опція лише для експертів, і
|
2026-06-25 23:08:58 +02:00
|
|
|
|
наполегливо не рекомендується її використовувати.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Ви НЕ маєте захисту даних під час операції `sync`.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
-W, --force-realloc-tail SIZE
|
2026-02-25 14:48:54 +01:00
|
|
|
|
Працює як -R, --force-realloc, але обмежується вказаною кінцевою
|
2026-06-25 23:08:58 +02:00
|
|
|
|
частиною (останні SIZE-байт) кожного файлу парності.
|
2026-02-25 14:48:54 +01:00
|
|
|
|
Примусово перерозподіляє (переміщує) будь-які фрагменти/блоки файлів,
|
|
|
|
|
|
що наразі зберігаються в цій кінцевій секції, дозволяючи розмістити
|
|
|
|
|
|
їх будь-де у файлі(ах) парності, де є вільне місце (включно з
|
|
|
|
|
|
наявними пустотами).
|
|
|
|
|
|
Основна мета цього параметра — зменшити розмір файлу парності на диску.
|
|
|
|
|
|
Якщо перерозподіл успішно очистить всю кінцеву секцію (у ній не
|
|
|
|
|
|
залишиться блоків), файл парності буде обрізаний, вивільняючи
|
|
|
|
|
|
невикористаний простір хвоста.
|
|
|
|
|
|
Можна використовувати множники, такі як K, M, G або T (наприклад,
|
|
|
|
|
|
--force-realloc-tail 1G).
|
|
|
|
|
|
Ви можете використовувати locate -t, --tail, щоб заздалегідь дізнатися
|
|
|
|
|
|
про зачеплені файли.
|
|
|
|
|
|
УВАГА!
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Цей параметр призначений лише для експертів, і його наполегливо
|
2026-02-25 14:48:54 +01:00
|
|
|
|
не рекомендується використовувати.
|
|
|
|
|
|
Під час операції `sync` захист даних для зачеплених файлів ВІДСУТНІЙ.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
-l, --log FILE
|
|
|
|
|
|
Записує детальний журнал у вказаний файл.
|
|
|
|
|
|
Якщо ця опція не вказана, несподівані помилки
|
|
|
|
|
|
виводяться на екран, що потенційно призводить до
|
|
|
|
|
|
надмірного виведення у випадку багатьох помилок.
|
|
|
|
|
|
Коли вказано -l, --log, на екран виводяться лише
|
|
|
|
|
|
фатальні помилки, які спричиняють зупинку SnapRAID.
|
2026-02-14 11:07:51 +01:00
|
|
|
|
Якщо шлях починається з `>>`, файл відкривається
|
|
|
|
|
|
у режимі доповнення. Входження `%D` та `%T` в
|
2025-12-13 19:34:07 +01:00
|
|
|
|
імені замінюються датою та часом у форматі YYYYMMDD
|
|
|
|
|
|
та HHMMSS. У пакетних файлах Windows ви повинні
|
2026-02-14 11:07:51 +01:00
|
|
|
|
подвоїти символ `%`, наприклад, result-%%D.log.
|
|
|
|
|
|
Щоб використовувати `>>`, ви повинні взяти ім'я
|
2025-12-13 19:34:07 +01:00
|
|
|
|
в лапки, наприклад, `">>result.log"`.
|
|
|
|
|
|
Щоб вивести журнал на стандартний вивід або
|
|
|
|
|
|
стандартну помилку, ви можете використовувати
|
|
|
|
|
|
`">&1"` та `">&2"` відповідно.
|
|
|
|
|
|
Дивіться файл snapraid_log.txt або man-сторінку
|
|
|
|
|
|
для описів тегів журналу.
|
|
|
|
|
|
|
|
|
|
|
|
-L, --error-limit NUMBER
|
|
|
|
|
|
Встановлює новий ліміт помилок перед зупинкою
|
|
|
|
|
|
виконання. За замовчуванням SnapRAID зупиняється,
|
|
|
|
|
|
якщо зустрічає більше 100 помилок введення/виведення,
|
|
|
|
|
|
що вказує на ймовірну відмову диска.
|
|
|
|
|
|
Ця опція впливає на `sync` та `scrub`, яким
|
|
|
|
|
|
дозволено продовжувати після першого набору
|
|
|
|
|
|
помилок диска, щоб спробувати завершити
|
|
|
|
|
|
свої операції. Однак `check` та `fix` завжди
|
|
|
|
|
|
зупиняються при першій помилці.
|
|
|
|
|
|
|
|
|
|
|
|
-S, --start BLKSTART
|
|
|
|
|
|
Починає обробку з вказаного номера блоку.
|
|
|
|
|
|
Це може бути корисно для повторної спроби
|
|
|
|
|
|
перевірки або виправлення певних блоків у
|
|
|
|
|
|
випадку пошкодженого диска.
|
|
|
|
|
|
Ця опція в основному для розширеного ручного
|
2026-08-14 00:28:30 +02:00
|
|
|
|
відновлення і підтримується лише `check` та `fix`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
-B, --count BLKCOUNT
|
|
|
|
|
|
Обробляє лише вказану кількість блоків.
|
|
|
|
|
|
Ця опція в основному для розширеного ручного
|
2026-08-14 00:28:30 +02:00
|
|
|
|
відновлення і підтримується лише `check` та `fix`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
-C, --gen-conf CONTENT
|
|
|
|
|
|
Генерує фіктивний конфігураційний файл з існуючого
|
|
|
|
|
|
файлу вмісту.
|
|
|
|
|
|
Конфігураційний файл записується на стандартний
|
|
|
|
|
|
вивід і не перезаписує існуючий.
|
|
|
|
|
|
Цей конфігураційний файл також містить інформацію,
|
|
|
|
|
|
необхідну для реконструкції точок монтування диска
|
|
|
|
|
|
у випадку втрати всієї системи.
|
|
|
|
|
|
|
|
|
|
|
|
-v, --verbose
|
|
|
|
|
|
Виводить більше інформації на екран.
|
|
|
|
|
|
Якщо вказано один раз, виводить виключені файли
|
|
|
|
|
|
та додаткову статистику.
|
|
|
|
|
|
Ця опція не впливає на файли журналу.
|
|
|
|
|
|
|
|
|
|
|
|
-q, --quiet
|
|
|
|
|
|
Виводить менше інформації на екран.
|
|
|
|
|
|
Якщо вказано один раз, видаляє індикатор прогресу;
|
|
|
|
|
|
двічі — поточні операції; тричі — інформаційні
|
|
|
|
|
|
повідомлення; чотири рази — повідомлення про
|
|
|
|
|
|
статус. Фатальні помилки завжди виводяться на
|
|
|
|
|
|
екран. Ця опція не впливає на файли журналу.
|
|
|
|
|
|
|
|
|
|
|
|
-H, --help
|
|
|
|
|
|
Виводить короткий довідковий екран.
|
|
|
|
|
|
|
|
|
|
|
|
-V, --version
|
|
|
|
|
|
Виводить версію програми.
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Конфігурація (Configuration)
|
2025-12-13 19:34:07 +01:00
|
|
|
|
SnapRAID вимагає конфігураційний файл, щоб знати, де
|
|
|
|
|
|
розташований ваш дисковий масив і де зберігати інформацію
|
|
|
|
|
|
парності.
|
|
|
|
|
|
|
|
|
|
|
|
В Unix використовується файл `/usr/local/etc/snapraid.conf`,
|
|
|
|
|
|
якщо він існує, інакше `/etc/snapraid.conf`.
|
|
|
|
|
|
У Windows використовується файл `snapraid.conf` у тому
|
|
|
|
|
|
самому каталозі, що й `snapraid.exe`.
|
|
|
|
|
|
|
|
|
|
|
|
Він повинен містити наступні опції (чутливі до регістру):
|
|
|
|
|
|
|
|
|
|
|
|
parity FILE [,FILE] ...
|
|
|
|
|
|
Визначає файли, які потрібно використовувати для зберігання
|
|
|
|
|
|
інформації парності. Парність забезпечує захист від
|
|
|
|
|
|
відмови одного диска, подібно до RAID5.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете вказати кілька файлів, які повинні бути на
|
|
|
|
|
|
різних дисках. Коли файл більше не може зростати,
|
|
|
|
|
|
використовується наступний.
|
|
|
|
|
|
Загальний доступний простір повинен бути принаймні
|
|
|
|
|
|
таким же великим, як найбільший диск даних у масиві.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете додати додаткові файли парності пізніше,
|
|
|
|
|
|
але ви не можете їх переупорядковувати або видаляти.
|
|
|
|
|
|
|
|
|
|
|
|
Збереження дисків парності зарезервованими для парності
|
|
|
|
|
|
забезпечує, що вони не стають фрагментованими, покращуючи
|
|
|
|
|
|
продуктивність.
|
|
|
|
|
|
|
|
|
|
|
|
У Windows 256 МБ залишається невикористаними на кожному
|
|
|
|
|
|
диску, щоб уникнути попередження про повні диски.
|
|
|
|
|
|
|
|
|
|
|
|
Ця опція є обов'язковою і може бути використана лише один раз.
|
|
|
|
|
|
|
|
|
|
|
|
(2,3,4,5,6)-parity FILE [,FILE] ...
|
|
|
|
|
|
Визначає файли, які потрібно використовувати для зберігання
|
|
|
|
|
|
додаткової інформації парності.
|
|
|
|
|
|
|
|
|
|
|
|
Для кожного вказаного рівня парності вмикається один
|
|
|
|
|
|
додатковий рівень захисту:
|
|
|
|
|
|
|
|
|
|
|
|
* 2-parity вмикає подвійну парність RAID6.
|
|
|
|
|
|
* 3-parity вмикає потрійну парність.
|
|
|
|
|
|
* 4-parity вмикає четверну парність.
|
|
|
|
|
|
* 5-parity вмикає п'ятерну парність.
|
|
|
|
|
|
* 6-parity вмикає шестерну парність.
|
|
|
|
|
|
|
|
|
|
|
|
Кожен рівень парності вимагає наявності всіх попередніх
|
|
|
|
|
|
рівнів парності.
|
|
|
|
|
|
|
2026-02-14 11:07:51 +01:00
|
|
|
|
Застосовуються ті самі міркування, що й для опції `parity`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Ці опції є необов'язковими і можуть бути використані лише
|
|
|
|
|
|
один раз.
|
|
|
|
|
|
|
|
|
|
|
|
z-parity FILE [,FILE] ...
|
|
|
|
|
|
Визначає альтернативний файл та формат для зберігання
|
|
|
|
|
|
потрійної парності.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Ця опція є альтернативою `3-parity`, насамперед
|
|
|
|
|
|
призначена для малопотужних ЦП, таких як ARM або
|
2025-12-13 19:34:07 +01:00
|
|
|
|
AMD Phenom, Athlon та Opteron, які не підтримують
|
|
|
|
|
|
набір інструкцій SSSE3. У таких випадках вона
|
|
|
|
|
|
забезпечує кращу продуктивність.
|
|
|
|
|
|
|
|
|
|
|
|
Цей формат схожий, але швидший, ніж той, що використовується
|
|
|
|
|
|
ZFS RAIDZ3. Як і ZFS, він не працює далі потрійної парності.
|
|
|
|
|
|
|
2026-02-14 11:07:51 +01:00
|
|
|
|
При використанні `3-parity` ви будете попереджені,
|
|
|
|
|
|
якщо рекомендується використовувати формат `z-parity`
|
2025-12-13 19:34:07 +01:00
|
|
|
|
для покращення продуктивності.
|
|
|
|
|
|
|
|
|
|
|
|
Можна конвертувати з одного формату в інший, налаштувавши
|
|
|
|
|
|
конфігураційний файл з бажаним файлом z-parity або
|
2026-02-14 11:07:51 +01:00
|
|
|
|
3-parity та використовуючи `fix` для його відтворення.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
content FILE
|
|
|
|
|
|
Визначає файл, який потрібно використовувати для зберігання
|
|
|
|
|
|
списку та контрольних сум усіх файлів, присутніх у
|
|
|
|
|
|
вашому дисковому масиві.
|
|
|
|
|
|
|
|
|
|
|
|
Він може бути розміщений на диску, що використовується для
|
|
|
|
|
|
даних, парності або будь-якому іншому доступному диску.
|
|
|
|
|
|
Якщо ви використовуєте диск даних, цей файл автоматично
|
|
|
|
|
|
виключається з процесу `sync`.
|
|
|
|
|
|
|
|
|
|
|
|
Ця опція є обов'язковою і може бути використана кілька
|
|
|
|
|
|
разів для збереження кількох копій одного і того ж
|
|
|
|
|
|
файлу.
|
|
|
|
|
|
|
|
|
|
|
|
Ви повинні зберігати принаймні одну копію для кожного
|
|
|
|
|
|
використаного диска парності плюс одну. Використання
|
|
|
|
|
|
додаткових копій не зашкодить.
|
|
|
|
|
|
|
|
|
|
|
|
data NAME DIR
|
|
|
|
|
|
Визначає ім'я та точку монтування дисків даних у
|
|
|
|
|
|
масиві. NAME використовується для ідентифікації диска
|
|
|
|
|
|
і має бути унікальним. DIR — це точка монтування
|
|
|
|
|
|
диска у файловій системі.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете змінювати точку монтування за потреби,
|
|
|
|
|
|
поки ви зберігаєте NAME фіксованим.
|
|
|
|
|
|
|
2026-08-26 00:31:56 +02:00
|
|
|
|
Однак налаштований шлях повинен постійно вказувати на ті самі
|
|
|
|
|
|
базові дані. Якщо шлях містить символічні посилання,
|
|
|
|
|
|
їхні цілі повинні залишатися стабільними. Перенаправлення
|
|
|
|
|
|
таких посилань для зміни каталогу даних на льоту не підтримується.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Ви повинні використовувати одну опцію для кожного
|
|
|
|
|
|
диска даних у масиві.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете перейменувати диск пізніше, змінивши NAME
|
|
|
|
|
|
безпосередньо у конфігураційному файлі, а потім
|
2026-02-14 11:07:51 +01:00
|
|
|
|
запустивши команду `sync`. У випадку перейменування
|
2025-12-13 19:34:07 +01:00
|
|
|
|
асоціація здійснюється за допомогою збереженого
|
|
|
|
|
|
UUID дисків.
|
|
|
|
|
|
|
2026-03-16 23:43:14 +01:00
|
|
|
|
extra NAME DIR
|
|
|
|
|
|
Визначає назву та точку монтування додаткових дисків для
|
|
|
|
|
|
моніторингу за допомогою команд `smart` та `probe`.
|
|
|
|
|
|
|
|
|
|
|
|
Це корисно для моніторингу дисків, які не є частиною масиву, але
|
|
|
|
|
|
необхідні для функціонування системи, наприклад, завантажувального
|
|
|
|
|
|
диска.
|
|
|
|
|
|
|
|
|
|
|
|
Зверніть увагу, що на такі диски не впливають команди `up` та `down`,
|
|
|
|
|
|
оскільки очікується, що вони завжди обертаються.
|
|
|
|
|
|
|
2026-06-08 18:26:17 +02:00
|
|
|
|
snapshot
|
|
|
|
|
|
Включає використання знімків файлової системи для команд `sync`, `scrub`,
|
|
|
|
|
|
`check` та `fix`.
|
|
|
|
|
|
|
2026-08-12 14:53:58 +02:00
|
|
|
|
Якщо увімкнено, SnapRAID створює знімок лише для читання кожної підтримуваної
|
|
|
|
|
|
файлової системи даних на початку операції 'sync'. Це забезпечує стабільний зріз
|
|
|
|
|
|
кожної файлової системи, запобігаючи зміні даних, що використовуються для обчислення
|
|
|
|
|
|
парності, подальшими модифікаціями.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
Це значно покращує відновлення: якщо файл видаляється з живої файлової системи,
|
|
|
|
|
|
він залишається збереженим у знімку. Це запобігає «порушенню» парності
|
|
|
|
|
|
для цього блоку, гарантуючи, що ви все одно зможете успішно відновити дані,
|
|
|
|
|
|
якщо інший диск зазнає збою.
|
|
|
|
|
|
|
|
|
|
|
|
Ця опція застосовується виключно до дисків із даними, відформатованих у файлових
|
|
|
|
|
|
системах Btrfs, Bcachefs або ZFS у Linux та NTFS у Windows.
|
|
|
|
|
|
Диски парності або диски з даними, що використовують інші файлові системи, завжди використовуватимуть
|
|
|
|
|
|
живу версію файлової системи.
|
|
|
|
|
|
|
|
|
|
|
|
Створення та видалення знімків вимагають прав адміністратора.
|
|
|
|
|
|
Переконайтеся, що SnapRAID запущено з необхідними привілеями (наприклад, sudo), коли
|
2026-06-25 23:08:58 +02:00
|
|
|
|
увімкнено цю опцію.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
Детальне пояснення життєвого циклу знімків див. у розділі SNAPSHOTS.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
nohidden
|
|
|
|
|
|
Виключає всі приховані файли та каталоги.
|
|
|
|
|
|
В Unix приховані файли — це ті, що починаються з `.`.
|
|
|
|
|
|
У Windows це ті, що мають прихований атрибут.
|
|
|
|
|
|
|
|
|
|
|
|
exclude/include PATTERN
|
|
|
|
|
|
Визначає шаблони файлів або каталогів для виключення
|
|
|
|
|
|
або включення у процес синхронізації.
|
|
|
|
|
|
Усі шаблони обробляються у вказаному порядку.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо перший шаблон, який збігається, є `exclude` (виключити),
|
|
|
|
|
|
файл виключається. Якщо він є `include` (включити),
|
|
|
|
|
|
файл включається.
|
|
|
|
|
|
Якщо жоден шаблон не збігається, файл виключається,
|
|
|
|
|
|
якщо останній вказаний шаблон є `include`, або
|
|
|
|
|
|
включається, якщо останній вказаний шаблон є `exclude`.
|
|
|
|
|
|
|
2026-08-26 12:29:13 +02:00
|
|
|
|
Зверніть увагу, що фільтрація відбувається ієрархічно під час
|
|
|
|
|
|
обходу каталогів. Якщо каталог відповідає правилу `exclude`, весь
|
|
|
|
|
|
каталог пропускається (відсікається), і будь-які правила `include`
|
|
|
|
|
|
для файлів або підкаталогів у ньому не оцінюватимуться.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Дивіться розділ PATTERN для отримання додаткової
|
|
|
|
|
|
інформації про специфікації шаблонів.
|
|
|
|
|
|
|
|
|
|
|
|
Цю опцію можна використовувати кілька разів.
|
|
|
|
|
|
|
|
|
|
|
|
blocksize SIZE_IN_KIBIBYTES
|
|
|
|
|
|
Визначає основний розмір блоку в кібібайтах для парності.
|
|
|
|
|
|
Один кібібайт дорівнює 1024 байтам.
|
|
|
|
|
|
|
|
|
|
|
|
Розмір блоку за замовчуванням становить 256, що має
|
|
|
|
|
|
працювати для більшості випадків.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
УВАГА! Ця опція лише для експертів, і наполегливо
|
2025-12-13 19:34:07 +01:00
|
|
|
|
не рекомендується змінювати це значення. Щоб змінити
|
|
|
|
|
|
це значення в майбутньому, вам потрібно буде
|
|
|
|
|
|
перестворити всю парність!
|
|
|
|
|
|
|
|
|
|
|
|
Причина використовувати інший розмір блоку полягає
|
|
|
|
|
|
в тому, якщо у вас є багато невеликих файлів, порядку
|
|
|
|
|
|
мільйонів.
|
|
|
|
|
|
|
|
|
|
|
|
Для кожного файлу, навіть якщо це лише кілька байтів,
|
|
|
|
|
|
виділяється цілий блок парності, і з багатьма файлами
|
|
|
|
|
|
це може призвести до значного невикористаного місця
|
|
|
|
|
|
парності. Коли ви повністю заповнюєте диск парності,
|
|
|
|
|
|
вам не дозволяється додавати більше файлів на диски
|
2026-06-25 23:08:58 +02:00
|
|
|
|
даних. Однак, втрачена парність не накопичується
|
|
|
|
|
|
між дисками даних. Марно втрачений простір внаслідок великої
|
2025-12-13 19:34:07 +01:00
|
|
|
|
кількості файлів на диску даних обмежує лише кількість
|
|
|
|
|
|
даних на цьому диску даних, а не на інших.
|
|
|
|
|
|
|
|
|
|
|
|
Як наближення, ви можете припустити, що половина
|
2026-06-25 23:08:58 +02:00
|
|
|
|
розміру блоку втрачається марно для кожного файлу.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Наприклад, зі 100 000 файлами та розміром блоку 256 КіБ
|
2026-06-25 23:08:58 +02:00
|
|
|
|
ви втратите 12,8 ГБ парності, що може призвести до
|
2025-12-13 19:34:07 +01:00
|
|
|
|
того, що на диску даних буде на 12,8 ГБ менше місця.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете перевірити кількість витраченого місця на
|
|
|
|
|
|
кожному диску за допомогою `status`. Це кількість
|
|
|
|
|
|
місця, яку ви повинні залишити вільною на дисках даних
|
|
|
|
|
|
або використовувати для файлів, не включених у масив.
|
|
|
|
|
|
Якщо це значення від'ємне, це означає, що ви
|
|
|
|
|
|
наближаєтеся до заповнення парності, і воно
|
|
|
|
|
|
представляє місце, яке ви ще можете витратити.
|
|
|
|
|
|
|
|
|
|
|
|
Щоб уникнути цієї проблеми, ви можете використовувати
|
|
|
|
|
|
більший розділ для парності. Наприклад, якщо розділ
|
|
|
|
|
|
парності на 12,8 ГБ більший за диски даних, у вас є
|
|
|
|
|
|
достатньо додаткового місця для обробки до 100 000
|
|
|
|
|
|
файлів на кожному диску даних без будь-якого
|
|
|
|
|
|
витраченого місця.
|
|
|
|
|
|
|
|
|
|
|
|
Хитрість, щоб отримати більший розділ парності в
|
|
|
|
|
|
Linux, полягає в тому, щоб відформатувати його
|
|
|
|
|
|
командою:
|
|
|
|
|
|
|
|
|
|
|
|
:mkfs.ext4 -m 0 -T largefile4 DEVICE
|
|
|
|
|
|
|
|
|
|
|
|
Це призводить до приблизно 1,5% додаткового місця,
|
|
|
|
|
|
приблизно 60 ГБ для диска 4 ТБ, що дозволяє
|
|
|
|
|
|
приблизно 460 000 файлів на кожному диску даних
|
|
|
|
|
|
без будь-якого витраченого місця.
|
|
|
|
|
|
|
|
|
|
|
|
hashsize SIZE_IN_BYTES
|
|
|
|
|
|
Визначає розмір хешу в байтах для збережених блоків.
|
|
|
|
|
|
|
|
|
|
|
|
Розмір хешу за замовчуванням становить 16 байтів
|
|
|
|
|
|
(128 біт), що має працювати для більшості випадків.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
УВАГА! Ця опція лише для експертів, і наполегливо
|
2025-12-13 19:34:07 +01:00
|
|
|
|
не рекомендується змінювати це значення. Щоб змінити
|
|
|
|
|
|
це значення в майбутньому, вам потрібно буде
|
|
|
|
|
|
перестворити всю парність!
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Інший розмір хешу варто використовувати, якщо ваша
|
|
|
|
|
|
система має обмежену пам'ять.
|
|
|
|
|
|
Зазвичай SnapRAID потребує 1 ГіБ ОЗП на кожні 16 ТБ
|
|
|
|
|
|
даних у масиві.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Зокрема, для зберігання хешів даних SnapRAID
|
2026-06-25 23:08:58 +02:00
|
|
|
|
вимагає приблизно TS*(1+HS)/BS байтів
|
2025-12-13 19:34:07 +01:00
|
|
|
|
ОЗП, де TS — загальний розмір вашого дискового масиву
|
|
|
|
|
|
у байтах, BS — розмір блоку у байтах, а HS —
|
|
|
|
|
|
розмір хешу у байтах.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, з 8 дисками по 4 ТБ, розміром блоку 256 КіБ
|
|
|
|
|
|
(1 КіБ = 1024 байта) та розміром хешу 16, ви отримуєте:
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
:RAM = (8 * 4 * 10^12) * (1+16) / (256 * 2^10) = 1.93 ГіБ
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Перехід до розміру хешу 8, ви отримуєте:
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
:RAM = (8 * 4 * 10^12) * (1+8) / (256 * 2^10) = 1.02 ГіБ
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Перехід до розміру блоку 512, ви отримуєте:
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
:RAM = (8 * 4 * 10^12) * (1+16) / (512 * 2^10) = 0.96 ГіБ
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Перехід до розміру хешу 8 та розміру блоку 512, ви отримуєте:
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
:RAM = (8 * 4 * 10^12) * (1+8) / (512 * 2^10) = 0.51 ГіБ
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
autosave SIZE_IN_GIGABYTES
|
|
|
|
|
|
Автоматично зберігає стан під час синхронізації або
|
|
|
|
|
|
скрабування після обробки вказаної кількості ГБ.
|
|
|
|
|
|
Ця опція корисна, щоб уникнути перезапуску довгих
|
|
|
|
|
|
команд `sync` з нуля, якщо вони були перервані
|
|
|
|
|
|
збоєм машини або будь-якою іншою подією.
|
|
|
|
|
|
|
|
|
|
|
|
temp_limit TEMPERATURE_CELSIUS
|
|
|
|
|
|
Встановлює максимальну дозволену температуру диска
|
|
|
|
|
|
в Цельсіях. Якщо вказано, SnapRAID періодично перевіряє
|
|
|
|
|
|
температуру всіх дисків за допомогою інструменту
|
|
|
|
|
|
smartctl. Поточні температури дисків відображаються
|
|
|
|
|
|
під час роботи SnapRAID. Якщо будь-який диск перевищує
|
|
|
|
|
|
цей ліміт, усі операції зупиняються, і диски
|
|
|
|
|
|
зупиняються (переходять у режим очікування) на час,
|
|
|
|
|
|
визначений опцією `temp_sleep`. Після періоду
|
|
|
|
|
|
очікування операції відновлюються, потенційно
|
|
|
|
|
|
знову призупиняючись, якщо ліміт температури знову
|
|
|
|
|
|
досягнутий.
|
|
|
|
|
|
|
|
|
|
|
|
Під час роботи SnapRAID також аналізує криву
|
|
|
|
|
|
нагрівання кожного диска та оцінює довгострокову
|
|
|
|
|
|
стабільну температуру, якої вони, як очікується,
|
|
|
|
|
|
досягнуть, якщо активність продовжиться.
|
|
|
|
|
|
Оцінка виконується лише після того, як температура
|
|
|
|
|
|
диска підвищилася чотири рази, що гарантує наявність
|
|
|
|
|
|
достатньої кількості даних для встановлення
|
|
|
|
|
|
надійного тренду. Ця прогнозована стабільна
|
|
|
|
|
|
температура відображається в дужках поруч із
|
|
|
|
|
|
поточним значенням і допомагає оцінити, чи
|
|
|
|
|
|
достатнє охолодження системи. Ця оцінювана
|
|
|
|
|
|
температура є лише інформаційною і не впливає на
|
|
|
|
|
|
поведінку SnapRAID. Дії програми базуються
|
|
|
|
|
|
виключно на фактично виміряних температурах
|
|
|
|
|
|
дисків.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Для виконання цього аналізу SnapRAID потрібне
|
|
|
|
|
|
опорне значення температури системи.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Спочатку він намагається зчитати її з доступних
|
|
|
|
|
|
апаратних датчиків. Якщо до системного датчика
|
|
|
|
|
|
неможливо отримати доступ, він використовує
|
|
|
|
|
|
найнижчу температуру диска, виміряну на початку
|
2026-06-25 23:08:58 +02:00
|
|
|
|
запуску, як резервне опорне значення.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Зазвичай SnapRAID показує лише температуру
|
|
|
|
|
|
найгарячішого диска. Щоб відобразити температуру
|
|
|
|
|
|
всіх дисків, використовуйте опцію -A або --stats.
|
|
|
|
|
|
|
|
|
|
|
|
temp_sleep TIME_IN_MINUTES
|
|
|
|
|
|
Встановлює час очікування, у хвилинах, коли
|
|
|
|
|
|
досягнуто ліміту температури. Протягом цього
|
|
|
|
|
|
періоду диски залишаються зупиненими.
|
|
|
|
|
|
За замовчуванням 5 хвилин.
|
|
|
|
|
|
|
|
|
|
|
|
pool DIR
|
|
|
|
|
|
Визначає каталог об'єднання, де створюється
|
|
|
|
|
|
віртуальне представлення дискового масиву за
|
|
|
|
|
|
допомогою команди `pool`.
|
|
|
|
|
|
|
|
|
|
|
|
Каталог повинен вже існувати.
|
|
|
|
|
|
|
|
|
|
|
|
share UNC_DIR
|
|
|
|
|
|
Визначає шлях Windows UNC, необхідний для
|
|
|
|
|
|
віддаленого доступу до дисків.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо ця опція вказана, символічні посилання,
|
|
|
|
|
|
створені в каталозі pool, використовують цей
|
|
|
|
|
|
шлях UNC для доступу до дисків.
|
|
|
|
|
|
Без цієї опції згенеровані символічні посилання
|
|
|
|
|
|
використовують лише локальні шляхи, що не
|
|
|
|
|
|
дозволяє спільно використовувати каталог pool
|
|
|
|
|
|
через мережу.
|
|
|
|
|
|
|
|
|
|
|
|
Символічні посилання формуються за допомогою
|
|
|
|
|
|
вказаного шляху UNC, додаючи ім'я диска, як
|
|
|
|
|
|
зазначено в опції `data`, і, нарешті,
|
|
|
|
|
|
додаючи каталог та ім'я файлу.
|
|
|
|
|
|
|
|
|
|
|
|
Ця опція потрібна лише для Windows.
|
|
|
|
|
|
|
|
|
|
|
|
smartctl DISK/PARITY OPTIONS...
|
|
|
|
|
|
Визначає користувацькі опції smartctl для
|
|
|
|
|
|
отримання атрибутів SMART для кожного диска.
|
|
|
|
|
|
Це може знадобитися для RAID-контролерів та
|
|
|
|
|
|
деяких USB-дисків, які не можуть бути
|
|
|
|
|
|
автоматично виявлені. Заповнювач %s
|
|
|
|
|
|
замінюється іменем пристрою, але він
|
|
|
|
|
|
необов'язковий для фіксованих пристроїв,
|
|
|
|
|
|
таких як RAID-контролери.
|
|
|
|
|
|
|
|
|
|
|
|
DISK — це те саме ім'я диска, вказане в опції `data`.
|
|
|
|
|
|
PARITY — це одне з імен парності: `parity`,
|
|
|
|
|
|
`2-parity`, `3-parity`, `4-parity`, `5-parity`,
|
|
|
|
|
|
`6-parity` або `z-parity`.
|
|
|
|
|
|
|
|
|
|
|
|
У вказаних OPTIONS рядок `%s` замінюється
|
|
|
|
|
|
іменем пристрою. Для RAID-контролерів пристрій
|
|
|
|
|
|
ймовірно фіксований, і вам може не знадобитися
|
|
|
|
|
|
використовувати `%s`.
|
|
|
|
|
|
|
2026-06-15 14:41:03 +02:00
|
|
|
|
Ви також можете вказати користувацький рядок параметрів інформації за допомогою
|
|
|
|
|
|
тега `[info: ...]`, щоб замінити параметр за замовчуванням `-a`.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Зверніться до документації smartmontools
|
|
|
|
|
|
для можливих опцій:
|
|
|
|
|
|
|
|
|
|
|
|
:https://www.smartmontools.org/wiki/Supported_RAID-Controllers
|
|
|
|
|
|
:https://www.smartmontools.org/wiki/Supported_USB-Devices
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад:
|
|
|
|
|
|
|
2026-06-15 14:41:03 +02:00
|
|
|
|
:smartctl d1 [info: -H -i -c -A] -d sat %s
|
2025-12-13 19:34:07 +01:00
|
|
|
|
:smartctl parity -d sat %s
|
|
|
|
|
|
|
|
|
|
|
|
smartignore DISK/PARITY ATTR [ATTR...]
|
|
|
|
|
|
Ігнорує вказаний атрибут SMART при обчисленні
|
|
|
|
|
|
ймовірності відмови диска. Ця опція корисна,
|
|
|
|
|
|
якщо диск повідомляє незвичайні або
|
|
|
|
|
|
оманливі значення для певного атрибута.
|
|
|
|
|
|
|
|
|
|
|
|
DISK — це те саме ім'я диска, вказане в опції `data`.
|
|
|
|
|
|
PARITY — це одне з імен парності: `parity`,
|
|
|
|
|
|
`2-parity`, `3-parity`, `4-parity`, `5-parity`,
|
|
|
|
|
|
`6-parity` або `z-parity`.
|
|
|
|
|
|
Спеціальне значення * можна використовувати
|
|
|
|
|
|
для ігнорування атрибута на всіх дисках.
|
|
|
|
|
|
|
2026-06-25 22:52:53 +02:00
|
|
|
|
Можна вказати кілька атрибутів, розділених пробілами.
|
|
|
|
|
|
Кожен атрибут може бути вказаний як число від 1 до 255 або як регістронезалежне
|
|
|
|
|
|
ім'я (наприклад, `Current_Pending_Sector`).
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-25 22:52:53 +02:00
|
|
|
|
Наприклад, щоб ігнорувати атрибути `Current Pending Sector Count` та
|
|
|
|
|
|
`Reallocated Sectors Count` на всіх дисках за їхнім номером або ім'ям:
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-25 22:52:53 +02:00
|
|
|
|
:smartignore * 197 5
|
|
|
|
|
|
:smartignore * Current_Pending_Sector Reallocated_Sector_Ct
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
2026-06-25 22:52:53 +02:00
|
|
|
|
Щоб ігнорувати їх лише на першому диску парності:
|
|
|
|
|
|
|
|
|
|
|
|
:smartignore parity 197 5
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Приклади
|
|
|
|
|
|
Приклад типової конфігурації для Unix:
|
|
|
|
|
|
|
|
|
|
|
|
:parity /mnt/diskp/snapraid.parity
|
|
|
|
|
|
:content /mnt/diskp/snapraid.content
|
|
|
|
|
|
:content /var/snapraid/snapraid.content
|
|
|
|
|
|
:data d1 /mnt/disk1/
|
|
|
|
|
|
:data d2 /mnt/disk2/
|
|
|
|
|
|
:data d3 /mnt/disk3/
|
|
|
|
|
|
:exclude /lost+found/
|
|
|
|
|
|
:exclude /tmp/
|
2026-06-15 14:41:03 +02:00
|
|
|
|
:smartctl d1 [info: -H -i -c -A] -d sat %s
|
2025-12-13 19:34:07 +01:00
|
|
|
|
:smartctl d2 -d usbjmicron %s
|
|
|
|
|
|
:smartctl parity -d areca,1/1 /dev/sg0
|
|
|
|
|
|
:smartctl 2-parity -d areca,2/1 /dev/sg0
|
|
|
|
|
|
|
|
|
|
|
|
Приклад типової конфігурації для Windows:
|
|
|
|
|
|
|
|
|
|
|
|
:parity E:\snapraid.parity
|
|
|
|
|
|
:content E:\snapraid.content
|
|
|
|
|
|
:content C:\snapraid\snapraid.content
|
|
|
|
|
|
:data d1 G:\array\
|
|
|
|
|
|
:data d2 H:\array\
|
|
|
|
|
|
:data d3 I:\array\
|
|
|
|
|
|
:exclude Thumbs.db
|
|
|
|
|
|
:exclude \$RECYCLE.BIN
|
|
|
|
|
|
:exclude \System Volume Information
|
2026-06-15 14:41:03 +02:00
|
|
|
|
:smartctl d1 [info: -H -i -c -A] -d sat %s
|
2025-12-13 19:34:07 +01:00
|
|
|
|
:smartctl d2 -d usbjmicron %s
|
|
|
|
|
|
:smartctl parity -d areca,1/1 /dev/arcmsr0
|
|
|
|
|
|
:smartctl 2-parity -d areca,2/1 /dev/arcmsr0
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Знімки (Snapshots)
|
2026-08-12 14:53:58 +02:00
|
|
|
|
Якщо в конфігурації увімкнено опцію знімків, SnapRAID використовує знімки
|
|
|
|
|
|
файлової системи для збереження стабільності даних, що зчитуються під час
|
|
|
|
|
|
операції, навіть якщо файли в живих файлових системах згодом змінюються
|
|
|
|
|
|
або видаляються.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
Керування знімками відбувається повністю автоматично та прозоро.
|
|
|
|
|
|
Ви можете продовжувати використовувати SnapRAID точно так само, як і раніше, отримуючи
|
|
|
|
|
|
додатковий захист, що забезпечується знімками, які повністю обробляються у
|
|
|
|
|
|
фоновому режимі.
|
|
|
|
|
|
|
|
|
|
|
|
Це дає дві основні переваги:
|
|
|
|
|
|
|
|
|
|
|
|
Узгодженість — Файли, змінені в живій файловій системі під час тривалого
|
|
|
|
|
|
процесу sync або scrub, не викликатимуть невідповідності парності або переривання
|
2026-08-12 14:53:58 +02:00
|
|
|
|
операцій, оскільки кожна файлова система зі знімком залишається незмінною
|
|
|
|
|
|
протягом усієї операції.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Відновлення — Якщо файл оновлюється або видаляється з живої файлової системи,
|
|
|
|
|
|
він залишається збереженим у знімку. Якщо збій диска станеться
|
|
|
|
|
|
до запуску наступної синхронізації sync, SnapRAID використає дані, збережені
|
|
|
|
|
|
в знімку, для реконструкції диска, що зазнав збою.
|
|
|
|
|
|
|
|
|
|
|
|
У разі збою диска під час активного процесу sync,
|
|
|
|
|
|
SnapRAID також може автоматично читати як зі знімка попереднього
|
|
|
|
|
|
обчислення парності, так і з поточного.
|
|
|
|
|
|
Це максимізує ймовірність повного відновлення, надаючи
|
|
|
|
|
|
доступ до точних блоків даних, необхідних для вирішення рівнянь парності,
|
|
|
|
|
|
навіть якщо ці блоки були змінені або видалені між синхронізаціями.
|
|
|
|
|
|
|
|
|
|
|
|
Без знімків оновлений або видалений файл на справному диску
|
|
|
|
|
|
призводить до відсутності блоків даних, які можуть знадобитися для
|
|
|
|
|
|
відновлення інших дисків, що зазнали збою.
|
|
|
|
|
|
|
|
|
|
|
|
Знімки створюються лише для дисків із даними і лише в тому випадку, якщо базова
|
|
|
|
|
|
файлова система підтримує цю функціональність. Диски парності завжди використовують
|
|
|
|
|
|
живу файлову систему.
|
2026-06-21 23:30:27 +02:00
|
|
|
|
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Наразі це підтримується на Btrfs, Bcachefs та ZFS в Linux
|
|
|
|
|
|
і на NTFS у Windows.
|
|
|
|
|
|
|
|
|
|
|
|
Ви можете комбінувати диски з даними з різними файловими системами. Тільки ті з них,
|
|
|
|
|
|
які підтримують знімки, використовуватимуть їх, тоді як інші диски продовжуватимуть
|
|
|
|
|
|
працювати безпосередньо з живою файловою системою.
|
|
|
|
|
|
|
|
|
|
|
|
Створення та видалення знімків вимагають прав адміністратора.
|
|
|
|
|
|
Переконайтеся, що SnapRAID запущено з необхідними привілеями (наприклад, sudo),
|
|
|
|
|
|
коли знімки увімкнено.
|
|
|
|
|
|
|
|
|
|
|
|
Поведінка команд із знімками
|
2026-08-12 14:53:58 +02:00
|
|
|
|
Команди `sync` та `scrub` використовують знімки для дисків із даними, чиї
|
|
|
|
|
|
файлові системи їх підтримують. На диску зі знімком команда бачить стабільний
|
|
|
|
|
|
образ файлової системи, не зачеплений одночасними змінами в живій файловій
|
|
|
|
|
|
системі.
|
|
|
|
|
|
Під час `sync` новий знімок створюється незалежно для кожної підтримуваної
|
|
|
|
|
|
файлової системи даних. Ці знімки сукупно надають дані, що використовуються
|
|
|
|
|
|
для обчислення парності.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Навпаки, команда `scrub` використовує останній знімок, створений під час
|
|
|
|
|
|
найостаннішої синхронізації, щоб підтримувати надійну точку відліку,
|
|
|
|
|
|
яка відповідає існуючій парності.
|
|
|
|
|
|
|
|
|
|
|
|
Для команд `check` та `fix` використання останнього знімка
|
|
|
|
|
|
залежить від того, чи націлені конкретні диски за допомогою опції
|
|
|
|
|
|
-d, --filter-disk.
|
|
|
|
|
|
|
|
|
|
|
|
Диск, явно вибраний за допомогою -d («ціль» операції),
|
|
|
|
|
|
завжди використовує живу файлову систему. Для `fix` це дозволяє відновити
|
|
|
|
|
|
дані на активну заміну диска. Для `check` це дозволяє симулювати
|
|
|
|
|
|
операцію `fix` за тих самих умов.
|
|
|
|
|
|
|
|
|
|
|
|
Доступ до всіх інших дисків із даними («довідкових» дисків) здійснюватиметься через
|
|
|
|
|
|
їхні знімки. Це гарантує, що навіть якщо ви змінюєте файли
|
|
|
|
|
|
на своїх справних дисках під час відновлення, SnapRAID
|
|
|
|
|
|
має стабільну, замороженну точку відліку для вирішення рівнянь парності.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо опція -d не надана, SnapRAID припускає, що операція застосовується
|
|
|
|
|
|
до всього масиву; у цьому випадку `check` та `fix` використовуватимуть виключно
|
|
|
|
|
|
живі файлові системи.
|
|
|
|
|
|
|
|
|
|
|
|
Усі інші команди працюють виключно з живою файловою системою.
|
|
|
|
|
|
|
2026-06-21 23:16:22 +02:00
|
|
|
|
Життєвий цикл знімків (Snapshots Lifecycle)
|
2026-08-12 14:53:58 +02:00
|
|
|
|
SnapRAID керує трьома конкретними знімками, `stable`, `pending` та `scan`,
|
2026-06-08 18:26:17 +02:00
|
|
|
|
всередині прихованого каталогу в корінному каталозі кожного підтому даних.
|
|
|
|
|
|
У Btrfs, Bcachefs та NTFS використовується каталог `.snapraid/`,
|
|
|
|
|
|
у ZFS — стандартний `.zfs/snapshot/`.
|
|
|
|
|
|
|
|
|
|
|
|
Знімок `stable` представляє стан останньої успішно
|
|
|
|
|
|
завершеної синхронізації `sync`, що містить точні дані, використані для
|
|
|
|
|
|
обчислення поточної парності. Він служить основним джерелом даних
|
|
|
|
|
|
для команд `scrub`, `check` та `fix`.
|
|
|
|
|
|
|
2026-08-12 14:53:58 +02:00
|
|
|
|
Знімок `scan` — це тимчасовий образ, що створюється на початку
|
|
|
|
|
|
`sync` для забезпечення замороженого стану для сканування та обчислення парності.
|
|
|
|
|
|
Після сканування та збереження нового стану вмісту він замінює попередній
|
|
|
|
|
|
знімок `pending`.
|
|
|
|
|
|
|
|
|
|
|
|
Знімок `pending` — це образ, використовуваний перерваною синхронізацією `sync`.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
Після успішного завершення операції попередній знімок `stable`
|
|
|
|
|
|
видаляється, а знімок `pending` підвищується в статусі, щоб
|
|
|
|
|
|
зайняти його місце в якості нового стабільного орієнтира.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо процес `sync` переривається, знімок `pending` зберігається.
|
|
|
|
|
|
Наступні команди `scrub`, `check` та `fix` використовуватимуть цей
|
|
|
|
|
|
очікуваний знімок, оскільки він відповідає стану файлової системи, записаному в
|
|
|
|
|
|
файлі .content, навіть якщо парність синхронізована лише частково.
|
|
|
|
|
|
|
|
|
|
|
|
У разі переривання `sync` команди `check` та `fix`
|
|
|
|
|
|
також читають дані зі знімка `stable` для вилучення блоків даних
|
|
|
|
|
|
із файлів, які були оновлені або видалені під час синхронізації.
|
|
|
|
|
|
Це можливо тому, що файл .content зберігає метадані для
|
|
|
|
|
|
усіх змінених або видалених файлів протягом усього процесу sync.
|
|
|
|
|
|
Ця історична інформація очищається лише після успішного завершення sync
|
|
|
|
|
|
і збереження фінальної версії файлу .content.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо `sync` перезапускається після переривання, існуючий
|
|
|
|
|
|
очікуваний (pending) знімок видаляється, і створюється новий для
|
|
|
|
|
|
фіксації поточного стану живої файлової системи.
|
2026-08-25 12:51:26 +02:00
|
|
|
|
Однак, якщо `sync` було перервано, уникайте зміни, видалення,
|
|
|
|
|
|
заміни або переміщення файлів, доки наступний `sync` не завершиться
|
|
|
|
|
|
успішно. Парність все ще може містити блоки, обчислені на основі знімка,
|
|
|
|
|
|
використаного перерваною синхронізацією. Пізніша синхронізація може
|
|
|
|
|
|
замінити цей знімок, зробивши проміжні версії файлів недоступними для
|
|
|
|
|
|
відновлення.
|
2026-06-08 18:26:17 +02:00
|
|
|
|
|
2026-10-01 19:55:23 +02:00
|
|
|
|
Зовнішнє резервне копіювання зі знімками файлової системи (External backups with filesystem snapshots)
|
|
|
|
|
|
Коли знімки файлової системи ввімкнено, SnapRAID звертається до знімків або
|
|
|
|
|
|
створює їх у корені кожного підтому даних, тому або набору даних (dataset).
|
|
|
|
|
|
|
|
|
|
|
|
Простий спосіб уникнути будь-яких конфліктів зі сторонніми інструментами —
|
|
|
|
|
|
вказати в налаштуванні `data` звичайний підкаталог усередині підтому або
|
|
|
|
|
|
тому (наприклад, `/mnt/subvol/data` замість `/mnt/subvol`). SnapRAID завжди
|
|
|
|
|
|
створює каталог знімків у корені підтому (наприклад,
|
|
|
|
|
|
`/mnt/subvol/.snapraid/`), залишивши підкаталог даних чистим, завдяки чому
|
|
|
|
|
|
знімки залишаться ззовні та будуть невидимими для засобів резервного
|
|
|
|
|
|
копіювання, що працюють у ньому.
|
|
|
|
|
|
|
|
|
|
|
|
В іншому випадку, якщо налаштований каталог `data` сам по собі є коренем
|
|
|
|
|
|
підтому або тому, SnapRAID створює каталог `.snapraid/` безпосередньо
|
|
|
|
|
|
всередині нього (у Btrfs, Bcachefs та NTFS). Хоча SnapRAID автоматично
|
|
|
|
|
|
виключає цей каталог із власного сканування, зовнішні інструменти
|
|
|
|
|
|
резервного копіювання або синхронізації файлів виявлять його. Якщо каталог
|
|
|
|
|
|
не виключено, вони можуть увійти у знімки або посилання на каталоги та
|
|
|
|
|
|
скопіювати все заморожене дерево даних, дублюючи файли й вичерпуючи
|
|
|
|
|
|
дисковий простір резервного сховища. Завжди налаштовуйте зовнішні засоби
|
|
|
|
|
|
резервного копіювання на виключення каталогу `.snapraid/`.
|
|
|
|
|
|
|
|
|
|
|
|
У ZFS знімки надаються через стандартний віртуальний каталог
|
|
|
|
|
|
`.zfs/snapshot/` замість `.snapraid/`. За замовчуванням (`snapdir=hidden`)
|
|
|
|
|
|
ZFS приховує цей каталог зі списків каталогів, тому зовнішні інструменти
|
|
|
|
|
|
резервного копіювання не скануватимуть його. Якщо ви ввімкнули
|
|
|
|
|
|
`snapdir=visible`, обов'язково переконайтеся, що ваші інструменти
|
|
|
|
|
|
резервного копіювання виключають каталог `.zfs/`.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Шаблон (Pattern)
|
2026-01-10 16:57:04 +01:00
|
|
|
|
Шаблони забезпечують гнучкий спосіб фільтрації файлів для включення або
|
|
|
|
|
|
виключення. Використовуючи символи підстановки (globbing), ви можете визначити правила, які
|
|
|
|
|
|
відповідають конкретним іменам файлів або цілим структурам каталогів без
|
|
|
|
|
|
ручного перерахування кожного шляху.
|
|
|
|
|
|
|
|
|
|
|
|
Знак питання `?` відповідає будь-якому одному символу, крім роздільника
|
|
|
|
|
|
каталогів. Це робить його корисним для зіставлення імен файлів із змінними
|
|
|
|
|
|
символами, при цьому шаблон обмежується одним рівнем каталогу.
|
|
|
|
|
|
|
|
|
|
|
|
Одинарна зірочка `*` відповідає будь-якій послідовності символів, але, як і
|
|
|
|
|
|
знак питання, вона ніколи не перетинає межі каталогів. Вона зупиняється на
|
|
|
|
|
|
прямій косій рисці, що робить її придатною для зіставлення всередині одного
|
|
|
|
|
|
компонента шляху. Це стандартна поведінка підстановочних знаків, знайома
|
|
|
|
|
|
з командної оболонки (shell globbing).
|
|
|
|
|
|
|
2026-08-26 14:38:06 +02:00
|
|
|
|
Символ підстановки подвійна зірочка `**` зіставляється через роздільники
|
|
|
|
|
|
каталогів лише тоді, коли він прилягає до роздільника каталогів (перед ним або
|
|
|
|
|
|
після нього стоїть скісна риска). У цій формі він відповідає нулю або більше
|
|
|
|
|
|
символам на кількох рівнях каталогів. Наприклад, `foo/**/bar` відповідає
|
|
|
|
|
|
`foo/bar`, `foo/a/bar` та `foo/a/b/bar`; `**/build` відповідає `build` та
|
|
|
|
|
|
`foo/bar/build`; а `src/**.js` відповідає `src/main.js` та
|
|
|
|
|
|
`src/ui/components/main.js`.
|
|
|
|
|
|
Окрема форма `/**/` не приймається як повний шаблон.
|
|
|
|
|
|
|
|
|
|
|
|
Коли `**` не прилягає до скісної риски, він поводиться як `*` і не відповідає
|
|
|
|
|
|
роздільникам каталогів. Наприклад, `**.jpg` відповідає `photo.jpg` у поточному
|
|
|
|
|
|
каталозі, але не відповідає `dir/photo.jpg`. Для цієї мети використовуйте
|
|
|
|
|
|
`**/*.jpg`.
|
2026-01-10 16:57:04 +01:00
|
|
|
|
|
|
|
|
|
|
Класи символів із використанням квадратних дужок `[]` відповідають одному символу з
|
|
|
|
|
|
визначеного набору або діапазону. Як і інші односимвольні шаблони, вони
|
|
|
|
|
|
не відповідають роздільникам каталогів. Класи підтримують діапазони та заперечення за допомогою
|
2026-06-25 23:08:58 +02:00
|
|
|
|
знака оклику.
|
2026-01-10 16:57:04 +01:00
|
|
|
|
|
|
|
|
|
|
Фундаментальна відмінність, яку слід пам'ятати, полягає в тому, що `*`, `?` та класи символів
|
|
|
|
|
|
усі дотримуються меж каталогів і відповідають лише в межах одного компонента
|
2026-08-26 14:38:06 +02:00
|
|
|
|
шляху, тоді як `**` може відповідати через роздільники каталогів лише тоді,
|
|
|
|
|
|
коли прилягає до скісної риски.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Існує чотири різні типи шаблонів:
|
|
|
|
|
|
|
|
|
|
|
|
=FILE
|
2026-01-10 16:57:04 +01:00
|
|
|
|
Вибирає будь-який файл з ім'ям FILE.
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Цей шаблон застосовується тільки до файлів, а не до каталогів.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
=DIR/
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Вибирає будь-який каталог з ім'ям DIR і все, що знаходиться всередині.
|
|
|
|
|
|
Цей шаблон застосовується тільки до каталогів, а не до файлів.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
=/PATH/FILE
|
2026-01-10 16:57:04 +01:00
|
|
|
|
Вибирає точно вказаний шлях до файлу. Цей шаблон застосовується
|
2026-06-25 23:08:58 +02:00
|
|
|
|
тільки до файлів, а не до каталогів.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
=/PATH/DIR/
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Вибирає точно вказаний шлях до каталогу і все, що знаходиться
|
|
|
|
|
|
всередині. Цей шаблон застосовується тільки до каталогів, а не до файлів.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Коли ви вказуєте абсолютний шлях, що починається
|
|
|
|
|
|
з /, він застосовується до кореневого каталогу
|
|
|
|
|
|
масиву, а не до кореневого каталогу локальної
|
|
|
|
|
|
файлової системи.
|
|
|
|
|
|
|
|
|
|
|
|
У Windows ви можете використовувати зворотну
|
|
|
|
|
|
скісну риску \ замість прямої скісної риски /.
|
|
|
|
|
|
Системні каталоги Windows, з'єднання, точки
|
|
|
|
|
|
монтування та інші спеціальні каталоги Windows
|
|
|
|
|
|
розглядаються як файли, що означає, що для
|
|
|
|
|
|
їх виключення ви повинні використовувати правило
|
|
|
|
|
|
файлу, а не правило каталогу.
|
|
|
|
|
|
|
2026-02-14 11:07:51 +01:00
|
|
|
|
Якщо ім'я файлу містить символи `*`, `?`, `[`,
|
|
|
|
|
|
або `]`, ви повинні екранувати їх, щоб уникнути
|
2026-06-25 23:08:58 +02:00
|
|
|
|
їх інтерпретації як символу глобінгу.
|
2026-02-14 11:07:51 +01:00
|
|
|
|
В Unix символом екранування є `\`; у Windows — `^`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Коли шаблон знаходиться в командному рядку,
|
|
|
|
|
|
ви повинні подвоїти символ екранування, щоб
|
|
|
|
|
|
запобігти його інтерпретації командною оболонкою.
|
|
|
|
|
|
|
|
|
|
|
|
У конфігураційному файлі ви можете використовувати
|
|
|
|
|
|
різні стратегії для фільтрації файлів, які потрібно
|
|
|
|
|
|
обробити.
|
|
|
|
|
|
Найпростіший підхід — використовувати лише
|
|
|
|
|
|
правила `exclude` для видалення всіх файлів та
|
|
|
|
|
|
каталогів, які ви не хочете обробляти.
|
|
|
|
|
|
Наприклад:
|
|
|
|
|
|
|
|
|
|
|
|
:# Виключає будь-який файл з іменем `*.unrecoverable`
|
|
|
|
|
|
:exclude *.unrecoverable
|
|
|
|
|
|
:# Виключає кореневий каталог `/lost+found`
|
|
|
|
|
|
:exclude /lost+found/
|
|
|
|
|
|
:# Виключає будь-який підкаталог з іменем `tmp`
|
|
|
|
|
|
:exclude tmp/
|
|
|
|
|
|
|
|
|
|
|
|
Протилежний підхід — визначити лише файли,
|
|
|
|
|
|
які ви хочете обробити, використовуючи лише
|
|
|
|
|
|
правила `include`. Наприклад:
|
|
|
|
|
|
|
|
|
|
|
|
:# Включає лише деякі каталоги
|
|
|
|
|
|
:include /movies/
|
|
|
|
|
|
:include /musics/
|
|
|
|
|
|
:include /pictures/
|
|
|
|
|
|
|
|
|
|
|
|
Останній підхід — змішувати правила `exclude`
|
|
|
|
|
|
та `include`. У цьому випадку порядок правил
|
|
|
|
|
|
важливий. Раніші правила мають пріоритет
|
|
|
|
|
|
над пізнішими.
|
|
|
|
|
|
Для спрощення ви можете спочатку перерахувати
|
|
|
|
|
|
всі правила `exclude`, а потім усі правила `include`.
|
|
|
|
|
|
Наприклад:
|
|
|
|
|
|
|
|
|
|
|
|
:# Виключає будь-який файл з іменем `*.unrecoverable`
|
|
|
|
|
|
:exclude *.unrecoverable
|
|
|
|
|
|
:# Виключає будь-який підкаталог з іменем `tmp`
|
|
|
|
|
|
:exclude tmp/
|
|
|
|
|
|
:# Включає лише деякі каталоги
|
|
|
|
|
|
:include /movies/
|
|
|
|
|
|
:include /musics/
|
|
|
|
|
|
:include /pictures/
|
|
|
|
|
|
|
2026-08-26 12:29:13 +02:00
|
|
|
|
Зверніть увагу, що виключення каталогу (за допомогою DIR/ або /ШЛЯХ/DIR/)
|
|
|
|
|
|
запобігає входу SnapRAID у цей каталог та його скануванню. Відповідно,
|
|
|
|
|
|
неможливо повторно включити файл або підкаталог, розташований усередині
|
|
|
|
|
|
виключеного батьківського каталогу, оскільки сканер ніколи не переходить у нього.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, наступна конфігурація НЕ включить `file.dat`, оскільки
|
|
|
|
|
|
`/keep/` відсікається до того, як `file.dat` буде перевірено:
|
|
|
|
|
|
|
|
|
|
|
|
:# НЕ працює як очікується: /keep/ повністю пропускається
|
|
|
|
|
|
:include /keep/file.dat
|
|
|
|
|
|
:exclude /keep/
|
|
|
|
|
|
|
|
|
|
|
|
Щоб виключити файли всередині каталогу, зберігши конкретні файли,
|
|
|
|
|
|
виключайте шаблон файлів усередині каталогу замість виключення самого каталогу:
|
|
|
|
|
|
|
|
|
|
|
|
:# Працює: /keep/ сканується, але інші файли всередині виключаються
|
|
|
|
|
|
:include /keep/file.dat
|
|
|
|
|
|
:exclude /keep/*
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
У командному рядку, використовуючи опцію -f,
|
|
|
|
|
|
ви можете використовувати лише шаблони `include`.
|
|
|
|
|
|
Наприклад:
|
|
|
|
|
|
|
|
|
|
|
|
:# Перевіряє лише файли .mp3.
|
|
|
|
|
|
:# В Unix використовуйте лапки, щоб уникнути
|
2026-06-25 23:08:58 +02:00
|
|
|
|
:# розширення глобінгу оболонкою.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
:snapraid -f "*.mp3" check
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
В Unix, при використанні символів глобінгу в
|
2025-12-13 19:34:07 +01:00
|
|
|
|
командному рядку, ви повинні взяти їх у лапки,
|
|
|
|
|
|
щоб запобігти їх розширенню оболонкою.
|
|
|
|
|
|
|
2026-01-10 16:30:35 +01:00
|
|
|
|
Ігнорування файлів (Ignore File)
|
|
|
|
|
|
На додаток до глобальних правил у файлі конфігурації, ви можете розміщувати
|
|
|
|
|
|
файли `.snapraidignore` в будь-якому каталозі всередині масиву для визначення
|
|
|
|
|
|
децентралізованих правил виключення.
|
|
|
|
|
|
|
|
|
|
|
|
Правила, визначені в `.snapraidignore`, застосовуються після правил у файлі
|
|
|
|
|
|
конфігурації. Це означає, що вони мають вищий пріоритет і можуть бути використані
|
|
|
|
|
|
для виключення файлів, які раніше були включені глобальною конфігурацією.
|
|
|
|
|
|
Фактично, якщо локальне правило збігається, файл виключається незалежно від
|
|
|
|
|
|
глобальних налаштувань включення.
|
|
|
|
|
|
|
|
|
|
|
|
Логіка шаблонів у `.snapraidignore` повторює глобальну конфігурацію, але
|
|
|
|
|
|
прив'язує шаблони до каталогу, в якому знаходиться файл:
|
|
|
|
|
|
|
|
|
|
|
|
=FILE
|
|
|
|
|
|
Вибирає будь-який файл із ім'ям FILE у цьому каталозі або нижче.
|
|
|
|
|
|
Це відповідає тим самим правилам підстановки, що і в глобальному шаблоні.
|
|
|
|
|
|
|
|
|
|
|
|
=DIR/
|
|
|
|
|
|
Вибирає будь-який каталог із ім'ям DIR та весь його вміст, що
|
|
|
|
|
|
знаходиться в цьому каталозі або нижче.
|
|
|
|
|
|
|
|
|
|
|
|
=/PATH/FILE
|
|
|
|
|
|
Вибирає точно вказаний файл відносно розташування
|
|
|
|
|
|
файлу `.snapraidignore`.
|
|
|
|
|
|
|
|
|
|
|
|
=/PATH/DIR/
|
|
|
|
|
|
Вибирає точно вказаний каталог та весь його вміст відносно
|
|
|
|
|
|
розташування файлу `.snapraidignore`.
|
|
|
|
|
|
|
|
|
|
|
|
На відміну від глобальної конфігурації, файли `.snapraidignore` підтримують
|
|
|
|
|
|
лише правила виключення; ви не можете використовувати шаблони `include` або заперечення (!).
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, якщо у вас є `.snapraidignore` у `/mnt/disk1/projects/`:
|
|
|
|
|
|
|
|
|
|
|
|
:# Виключає ТІЛЬКИ /mnt/disk1/projects/output.bin
|
|
|
|
|
|
:/output.bin
|
2026-02-14 11:07:51 +01:00
|
|
|
|
:# Виключає будь-який каталог із назвою `build` всередині projects/
|
2026-01-10 16:30:35 +01:00
|
|
|
|
:build/
|
|
|
|
|
|
:# Виключає будь-який .tmp файл всередині projects/ або його підпапок
|
|
|
|
|
|
:*.tmp
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Вміст (Content)
|
|
|
|
|
|
SnapRAID зберігає список та контрольні суми
|
|
|
|
|
|
ваших файлів у файлі вмісту.
|
|
|
|
|
|
|
|
|
|
|
|
Це бінарний файл, який перераховує всі файли,
|
|
|
|
|
|
присутні у вашому дисковому масиві, разом з
|
|
|
|
|
|
усіма контрольними сумами для перевірки їх
|
|
|
|
|
|
цілісності.
|
|
|
|
|
|
|
2026-06-21 22:52:52 +02:00
|
|
|
|
Файл вмісту зчитується та записується командами `sync`, `scrub`,
|
|
|
|
|
|
`touch` та `rehash`. Він зчитується командами `status`, `diff`,
|
|
|
|
|
|
`check`, `fix`, `list`, `dup`, `locate` та `pool`, і повністю
|
|
|
|
|
|
ігнорується командами `smart`, `probe`, `up`, `down` та `devices`.
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Парність (Parity)
|
|
|
|
|
|
SnapRAID зберігає інформацію парності вашого
|
|
|
|
|
|
масиву у файлах парності.
|
|
|
|
|
|
|
|
|
|
|
|
Це бінарні файли, що містять обчислену
|
|
|
|
|
|
парність усіх блоків, визначених у файлі
|
|
|
|
|
|
`content`.
|
|
|
|
|
|
|
|
|
|
|
|
Ці файли зчитуються та записуються командами
|
|
|
|
|
|
`sync` та `fix` і лише зчитуються командами
|
|
|
|
|
|
`scrub` та `check`.
|
|
|
|
|
|
|
|
|
|
|
|
Кодування (Encoding)
|
|
|
|
|
|
SnapRAID в Unix ігнорує будь-яке кодування.
|
|
|
|
|
|
Він зчитує та зберігає імена файлів з
|
|
|
|
|
|
тим самим кодуванням, що використовується
|
|
|
|
|
|
файловою системою.
|
|
|
|
|
|
|
|
|
|
|
|
У Windows усі імена, зчитані з файлової
|
|
|
|
|
|
системи, конвертуються та обробляються
|
|
|
|
|
|
у форматі UTF-8.
|
|
|
|
|
|
|
|
|
|
|
|
Щоб імена файлів відображалися правильно,
|
|
|
|
|
|
ви повинні встановити консоль Windows
|
|
|
|
|
|
у режим UTF-8 за допомогою команди
|
|
|
|
|
|
`chcp 65001` та використовувати шрифт
|
|
|
|
|
|
TrueType, такий як `Lucida Console`, як
|
|
|
|
|
|
шрифт консолі.
|
|
|
|
|
|
Це впливає лише на надруковані імена
|
|
|
|
|
|
файлів; якщо ви перенаправляєте вивід
|
|
|
|
|
|
консолі у файл, отриманий файл завжди
|
|
|
|
|
|
буде у форматі UTF-8.
|
|
|
|
|
|
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Код завершення (Exit Code)
|
|
|
|
|
|
SnapRAID завершує роботу з такими кодами помилок:
|
|
|
|
|
|
|
|
|
|
|
|
0 - Все в порядку.
|
|
|
|
|
|
1 - Команда виявила помилки.
|
|
|
|
|
|
2 - Команда `diff` визначила, що все в порядку, але потрібен `sync`.
|
2026-09-18 23:28:47 +02:00
|
|
|
|
3 - Команда дискового пристрою (`probe`, `smart`, `devices`, `up`,
|
|
|
|
|
|
`down`) завершена, але принаймні одна файлова система працює
|
|
|
|
|
|
у деградованому режимі з відсутніми пристроями.
|
2026-06-25 23:08:58 +02:00
|
|
|
|
|
2026-08-26 10:00:16 +02:00
|
|
|
|
Відомі проблеми (Known Issues)
|
|
|
|
|
|
Межі файлової системи
|
|
|
|
|
|
SnapRAID не перетинає межі файлових систем, точок монтування або підтомів
|
|
|
|
|
|
під час сканування диска даних. Коли виявляється така межа, SnapRAID
|
|
|
|
|
|
повідомляє ПОПЕРЕДЖЕННЯ і не виконує сканування за її межами.
|
|
|
|
|
|
|
|
|
|
|
|
Файли, розташовані за такими межами, не включаються до диска даних і
|
|
|
|
|
|
повинні бути налаштовані окремо, якщо їх потрібно захистити.
|
|
|
|
|
|
|
|
|
|
|
|
Точки монтування зі знімками файлової системи
|
|
|
|
|
|
Коли знімки файлової системи увімкнено, вкладені точки монтування та
|
|
|
|
|
|
bind-монтування всередині диска даних не підтримуються.
|
|
|
|
|
|
|
|
|
|
|
|
Точки монтування є частиною простору імен монтування працюючої системи і
|
|
|
|
|
|
не зберігаються у знімках файлової системи. Отже, під час сканування знімка
|
|
|
|
|
|
каталог, прихований точкою монтування в активній файловій системі, може
|
|
|
|
|
|
стати видимим.
|
|
|
|
|
|
|
|
|
|
|
|
Не розміщуйте вкладені точки монтування або bind-монтування всередині дисків
|
|
|
|
|
|
даних, коли ввімкнено знімки файлової системи.
|
|
|
|
|
|
|
2026-09-08 10:52:00 +02:00
|
|
|
|
Кілька конфігурацій зі знімками файлової системи
|
|
|
|
|
|
Підтримка знімків не може безпечно спільно використовуватися кількома
|
|
|
|
|
|
незалежними конфігураціями SnapRAID, які використовують один і той самий
|
|
|
|
|
|
простір імен знімків файлової системи.
|
|
|
|
|
|
|
|
|
|
|
|
У Btrfs та Bcachefs лише одна конфігурація SnapRAID з увімкненою підтримкою
|
|
|
|
|
|
знімків може використовувати каталоги даних у межах одного підтому. У ZFS
|
|
|
|
|
|
це ж обмеження стосується датасету, а в NTFS — тому.
|
|
|
|
|
|
|
|
|
|
|
|
Кілька конфігурацій, які спільно використовують один і той самий простір
|
|
|
|
|
|
імен знімків, використовують однакові знімки `stable`, `pending` та `scan`.
|
|
|
|
|
|
Запуск однієї конфігурації може замінити або видалити знімки відновлення,
|
|
|
|
|
|
необхідні для іншої.
|
|
|
|
|
|
|
2026-08-26 10:00:16 +02:00
|
|
|
|
Модифікації файлів на місці без зміни позначок часу
|
|
|
|
|
|
SnapRAID виявляє модифікації файлів шляхом порівняння розмірів файлів та
|
|
|
|
|
|
позначок часу модифікації (mtime).
|
|
|
|
|
|
|
|
|
|
|
|
Якщо програма змінює файл на місці без зміни його розміру або оновлення
|
|
|
|
|
|
позначки часу модифікації, "diff" та "sync" не виявлять, що файл змінився,
|
|
|
|
|
|
і його парність не буде оновлено.
|
|
|
|
|
|
|
|
|
|
|
|
Щоб гарантувати, що SnapRAID розпізнає такі зміни, оновіть позначку часу
|
|
|
|
|
|
модифікації файлу (наприклад, за допомогою утиліти "touch"). В іншому
|
|
|
|
|
|
випадку різниця буде виявлена лише як невідповідність хешу під час
|
|
|
|
|
|
наступного "scrub" або "check".
|
|
|
|
|
|
|
2026-08-26 15:17:33 +02:00
|
|
|
|
Зіставлення регістру символів non-ASCII у Windows
|
|
|
|
|
|
SnapRAID використовує стандартне, передбачуване кодування UTF-8 на всіх
|
|
|
|
|
|
платформах, обмежуючи нечутливе до регістру зіставлення символами ASCII.
|
|
|
|
|
|
|
|
|
|
|
|
Файлові системи Windows страждають від застарілого архітектурного рішення,
|
|
|
|
|
|
що нав'язує нечутливість до регістру для імен файлів Unicode за допомогою
|
|
|
|
|
|
довільних, залежних від системи таблиць перетворення. Як наслідок, Windows
|
|
|
|
|
|
приховує реальність файлової системи, обробляючи абсолютно різні
|
|
|
|
|
|
послідовності байтів Unicode так, ніби це один і той самий файл.
|
|
|
|
|
|
|
|
|
|
|
|
Наприклад, `À.txt` та `à.txt` є різними іменами Unicode, але Windows нелогічно
|
|
|
|
|
|
вважає їх ідентичними, тоді як SnapRAID зберігає їхню справжню відмінність.
|
|
|
|
|
|
|
|
|
|
|
|
Це обмеження спричинене непослідовною обробкою імен файлів Unicode у Windows
|
|
|
|
|
|
та її наполегливим використанням псевдонімів без урахування регістру. Щоб
|
|
|
|
|
|
запобігти розбіжностям через зведення регістру у Windows, завжди вказуйте
|
|
|
|
|
|
точний регістр для будь-яких символів non-ASCII у шляхах конфігурації та
|
|
|
|
|
|
фільтрах.
|
|
|
|
|
|
|
2026-09-07 14:00:27 +02:00
|
|
|
|
Відновлення з частковим fix
|
|
|
|
|
|
Коли `fix` обмежено за допомогою `-S, --start` або `-B, --count`,
|
|
|
|
|
|
SnapRAID працює лише з вибраними блоками і не виконує фіналізацію
|
|
|
|
|
|
на рівні файлів або переміщення в карантин.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо в результаті відновлення отримано дані найкращої спроби (best-effort),
|
|
|
|
|
|
щодо яких не можна довести відповідність поточному вмісту, такі блоки все
|
|
|
|
|
|
одно можуть бути записані під звичайним ім'ям файлу. Невизначеність, пов'язана
|
|
|
|
|
|
з цими відновленими блоками, не зберігається після завершення команди.
|
|
|
|
|
|
|
|
|
|
|
|
Як наслідок, наступний `fix` сприйматиме ці доступні для читання блоки як дійсні
|
|
|
|
|
|
дані файлу і не намагатиметься відновити їх знову. Це може призвести до того,
|
|
|
|
|
|
що подальше відновлення повідомить про успіх, залишивши у файлі неповні або
|
|
|
|
|
|
застарілі дані.
|
|
|
|
|
|
|
|
|
|
|
|
Параметри `-S` та `-B` призначені лише для розширеного ручного відновлення,
|
|
|
|
|
|
зазвичай після збою звичайного `fix`. Якщо частковий `fix` повідомляє про
|
|
|
|
|
|
невідновлювані дані, видаліть або перейменуйте уражені файли перед спробою
|
|
|
|
|
|
повторного відновлення або перевірте їхній вміст вручну.
|
|
|
|
|
|
|
2026-09-07 17:16:24 +02:00
|
|
|
|
Жорсткі посилання NTFS та виключені шляхи
|
|
|
|
|
|
У файловій системі NTFS записи каталогів кешують розмір файлу та часові
|
|
|
|
|
|
позначки незалежно для кожного жорсткого посилання. Коли файл змінюється
|
|
|
|
|
|
через одне посилання, записи каталогів інших посилань, що вказують на
|
|
|
|
|
|
той самий файл, можуть зберігати застарілі метадані, доки до них не
|
|
|
|
|
|
буде здійснено доступ.
|
|
|
|
|
|
|
|
|
|
|
|
SnapRAID автоматично виявляє та нормалізує цей стан щоразу, коли під
|
|
|
|
|
|
час сканування виявляється щонайменше два жорстких посилання на один
|
|
|
|
|
|
і той самий файл. Однак, якщо сканується лише одне жорстке посилання,
|
|
|
|
|
|
тоді як інші виключені фільтрами або знаходяться за межами шляху диска
|
|
|
|
|
|
даних, SnapRAID не може виявити колізію inode і покладається на
|
|
|
|
|
|
кешовані метадані єдиного видимого посилання.
|
|
|
|
|
|
|
|
|
|
|
|
Отже, зміни, внесені через виключене або зовнішнє жорстке посилання,
|
|
|
|
|
|
можуть залишитися непоміченими для SnapRAID, доки метадані включеного
|
|
|
|
|
|
посилання не будуть оновлені операційною системою (наприклад, коли до
|
|
|
|
|
|
файлу звертаються або відкривають його за цим шляхом).
|
|
|
|
|
|
|
|
|
|
|
|
Щоб уникнути цього обмеження, не змінюйте захищені файли через жорсткі
|
|
|
|
|
|
посилання, виключені зі SnapRAID, або переконайтеся, що всі жорсткі
|
|
|
|
|
|
посилання на файл включені до сканування, щоб SnapRAID міг їх нормалізувати.
|
|
|
|
|
|
|
2026-09-08 09:10:20 +02:00
|
|
|
|
Відновлення після перерваного sync з кількома парностями
|
|
|
|
|
|
У масиві з кількома дисками парності перерваний `sync` може залишити
|
|
|
|
|
|
рівні парності тимчасово розсинхронізованими між собою. Наприклад,
|
|
|
|
|
|
парність 1 вже може містити оновлені дані, тоді як парність 2 все ще
|
|
|
|
|
|
містить старі дані.
|
|
|
|
|
|
|
|
|
|
|
|
Під час виконання `check` або `fix` SnapRAID випробовує різні комбінації
|
|
|
|
|
|
парностей і перевіряє відновлені дані за відомими хешами блоків
|
|
|
|
|
|
(що охоплюють блок цілком, зазвичай 256 КіБ).
|
|
|
|
|
|
|
|
|
|
|
|
Якщо SnapRAID намагається виконати відновлення, використовуючи
|
|
|
|
|
|
неузгоджену суміш старої та нової парності, лінійні рівняння RAID
|
|
|
|
|
|
дадуть неправильні дані. Щоб така недійсна комбінація була помилково
|
|
|
|
|
|
прийнята, рівняння мали б випадково відновити хоча б один повний блок
|
|
|
|
|
|
розміром 256 КіБ настільки ідеально, щоб його хеш збігся, тоді як інші
|
|
|
|
|
|
несинхронізовані блоки в тій самій смузі будуть відновлені з помилковими
|
|
|
|
|
|
даними.
|
|
|
|
|
|
|
|
|
|
|
|
Цей сценарій не залежить від колізії хешів; навпаки, самі рівняння
|
|
|
|
|
|
змішаної парності мали б випадково відтворити точний вихідний вміст
|
|
|
|
|
|
256-КіБ блоку. Хоча це математично можливо для спеціально підготовлених
|
|
|
|
|
|
або сильно повторюваних даних, на реальних даних це практично неможливо.
|
|
|
|
|
|
|
|
|
|
|
|
Якщо всі диски справні, завершення перерваного `sync` перед внесенням
|
|
|
|
|
|
подальших змін усуває цю неоднозначність. Якщо диск вийшов з ладу і
|
|
|
|
|
|
потрібне відновлення, уникайте змін на дисках даних перед запуском
|
|
|
|
|
|
`check` або `fix`.
|
|
|
|
|
|
|
2026-09-25 17:09:49 +02:00
|
|
|
|
Зарезервовані імена файлів і каталогів
|
|
|
|
|
|
SnapRAID резервує деякі імена файлів, каталогів і знімків для своїх
|
|
|
|
|
|
внутрішніх операцій. Не використовуйте ці імена для даних користувача:
|
|
|
|
|
|
|
|
|
|
|
|
.snapraidignore - Локальний файл правил виключення.
|
|
|
|
|
|
.snapraid - Каталог-контейнер знімків.
|
|
|
|
|
|
snapraid-* - Імена знімків ZFS, керованих SnapRAID.
|
|
|
|
|
|
*.unrecoverable - Пошкоджені файли, поміщені в карантин під час
|
|
|
|
|
|
відновлення.
|
|
|
|
|
|
CONTENT.tmp - Тимчасовий файл для оновлень файлу content.
|
|
|
|
|
|
CONTENT.lock - Файл блокування файлу content.
|
|
|
|
|
|
PARITY.spaceholder - Тимчасовий файл резервування місця під час виділення
|
|
|
|
|
|
парності у Windows.
|
|
|
|
|
|
|
|
|
|
|
|
Використання цих імен для непов'язаних даних може призвести до того, що
|
|
|
|
|
|
файли або знімки будуть проігноровані, помилково сприйняті як метадані,
|
|
|
|
|
|
перезаписані, перейменовані або видалені.
|
|
|
|
|
|
|
|
|
|
|
|
У Windows усі варіанти регістру також зарезервовані, навіть у каталогах
|
|
|
|
|
|
NTFS, налаштованих з урахуванням регістру (наприклад, .SNAPRAIDIGNORE,
|
|
|
|
|
|
.SnapRaid, CONTENT.TMP та CONTENT.Lock).
|
|
|
|
|
|
|
2026-06-21 23:36:09 +02:00
|
|
|
|
Переклад (Translation)
|
|
|
|
|
|
Цей документ є автоматичним перекладом англійського посібника.
|
|
|
|
|
|
Зверніться до англійського посібника для отримання офіційної версії.
|
|
|
|
|
|
|
2025-12-13 19:34:07 +01:00
|
|
|
|
Авторське право (Copyright)
|
2026-06-25 23:08:58 +02:00
|
|
|
|
Цей файл захищений авторським правом (C) 2026 Andrea Mazzoleni
|
2025-12-13 19:34:07 +01:00
|
|
|
|
|
|
|
|
|
|
Див. також (See Also)
|
2026-06-21 23:30:27 +02:00
|
|
|
|
snapraid_log(1), snapraidd(1), rsync(1)
|