Резервне копіювання Windows на NAS: налаштування, що не підводить випадково

Про що ми насправді говоримо (і про що ні)

Ми будуємо надійні резервні копії Windows на NAS через SMB з такими елементами:

• Два типи резервних копій: файлові копії (Robocopy) та опціонально образні копії (Windows Server Backup до SMB там, де це доречно).
• Контрольована ідентичність: виділений обліковий запис для бекапу, стабільні облікові дані, ніяких сюрпризів «хто востаннє запускав завдання?».
• Передбачуваний ввід/вивід: налаштування SMB, що не самосаботують, і рішення зберігання на NAS, які не розсипляться під навантаженням з дрібними файлами.
• Докази: логи, коди виходу, збереження, верифікація та вправи з відновлення.
• Швидкість діагностики: ви швидко зрозумієте, чи вузьке місце — DNS, автентифікація, узгодження SMB, диск, CPU, MTU чи накладання розкладів.

Ми не стверджуємо, що це замінює правильну стратегію 3-2-1. Загальнодоступна шарова директорія NAS — не віддалена копія, не невразлива за замовчуванням і не захищена від рансомваре, якщо ви цього не забезпечите.

Факти та контекст: чому Windows→NAS поводиться дивно

Деякий фон важливий, бо режими відмови закладені історично, а не у вашій компетенції.

1. SMB старий. Родовід протоколу сягає 1980-х; шари сумісності досі переслідують сучасні розгортання «дружніми» за замовчуванням налаштуваннями.
2. SMB1 фактично => скам’янілість. Його часто експлуатували (черв’яки, бокова ескалація); сучасні версії Windows за замовчуванням вимикають його в багатьох редакціях з вагомих причин.
3. «Мережевий шар» і «ціль бекапу» — різні тварини. Файлові шари створені для інтерактивного доступу; бекапи ж навантажують метадані і створюють великі послідовні потоки, часто в одній задачі.
4. Файлова семантика Windows сувора. Alternate data streams, довгі шляхи, ACL і робота з відкритими файлами — звична річ; багато NAS-пристроїв імітують це неповно.
5. VSS існує, бо додатки Windows не закривають файли ввічливо. Тіньові копії були введені для отримання консистентних снапшотів, поки додатки продовжують запис.
6. SMB signing став базовим рівнем безпеки. Багато середовищ вимагають його; це може впливати на пропускну здатність на слабших CPU NAS або при великій concurency.
7. Несинхронний час ламає автентифікацію неочевидно. Kerberos і терміни токенів не зважають на «лише п’ять хвилин.» Завдання бекапу падають, ніби їх переслідують привиди.
8. Вендори NAS оптимізують під змішані навантаження. Ваше навантаження бекапу (мільйони дрібних файлів, потім великі потоки) — найгірше з обох світів.
9. «Успіх» часто означає «успіх-нібито». Інструменти можуть повернути 0 з пропущеними файлами, виключеними junction-ами або проблемами шляхів, якщо ви не трактуєте логи як доказ.

Цитата, яку варто пам’ятати, бо вона — суть роботи: На надії стратегії не побудуєш. (парафраз, поширена ідея в операційних колах)

Принципи дизайну, що запобігають випадковим збоям

1) Зробіть ідентичність нудною: один обліковий запис бекапу на область

Створіть виділений обліковий запис (локальний або доменний), який використовується тільки для бекапів. Дайте йому права на читання джерел (або права адміністратора лише якщо необхідно, але не починайте з цього), і права на запис/створення на ціль NAS де можливо. Уникайте використання власного адмін-токена для планових бекапів. Політика ротації паролів рано чи пізно конфліктуватиме з Task Scheduler — і виживе лише один.

2) Зробіть шар на NAS спеціалізованим

Загальний шар «Public» — це шлях до хаосу збереження і допомога програмі-вимагачу. Створіть шар тільки для бекапів з такими атрибутами:

• окремий dataset/том (щоб могли робити снапшоти та застосовувати квоти)
• окремий SMB-шар (щоб налаштовувати параметри без порушення шарів користувачів)
• окремі права (щоб «випадкове видалення» вимагало зусиль)

3) Віддавайте перевагу «push» якщо ви його можете захистити

Копіювання даних з Windows на NAS (push) — звично і нормально. «Pull» (NAS підключається до Windows і копіює) може зменшити кількість облікових даних на кінцевих точках, але часто гірший для прав Windows і консистентності VSS. Якщо треба вибирати, push зазвичай простіший для правильного налаштування — після цього загартуйте NAS так, щоб передані дані не могли бути змінені пізніше.

4) Усуньте шляхи до тихих відмов

Бекапи голосно падають, коли мережа недоступна. Тихо — коли:

• ви потрапляєте в ліміти довжини шляху
• обліковий запис бекапу не може прочитати підмножину папок
• завдання працює довше за наступний запланований запуск (накладання)
• NAS закінчує inodes / простір метаданих / резерв для снапшотів
• SMB-сесії обриваються через таймаути бездіяльності під час передачі

Проектуйте для виявлення: явні перевірки кодів виходу, відправка логів та періодичні тести відновлення.

5) Не дозволяйте «оптимізації» випереджати спостережуваність

Стиснення, дедуп, багатопотокове копіювання, великі MTU, jumbo reads — це може дати вигоду. Але також робить збої переривчастими і важкими для відтворення. Оптимізуйте лише після того, як виміряли базову пропускну здатність і частоту помилок.

Жарт №1: Бекапи як парашути: той момент, коли він потрібен, — поганий час виявити, що ви купили «потрібна збірка».

Налаштування NAS, що витримує реальність

Виберіть схему зберігання, що відповідає IO бекапу

Бекапи зазвичай інтенсивно записують і вибухоподібні. Файлові бекапи можуть бути важкими для метаданих (дрібні файли), тоді як образні бекапи — великі послідовні записи. Ваш NAS має мати:

• Достатньо RAM, щоб уникати трешування кешів метаданих.
• Диски, що витримують запис без різкого падіння продуктивності (SMR-диски — відомий «сюрприз» для тривалих записів).
• Редунданс відповідно до бізнес-наслідків (mirror/RAIDZ/RAID6 тощо).

Якщо ваш NAS на ZFS — будьте обережні з дедупом. Це не безплатний ланч; це регулярні витрати в RAM і CPU.

Параметри SMB: спочатку безпека, потім продуктивність

За замовчуванням у різних постачальників по-різному. Загалом вам потрібно:

• SMB2/SMB3 тільки (відключіть SMB1).
• Шифрування: увімкніть, якщо трафік проходить незахищеними мережами; інакше оцініть вплив на CPU.
• Підписування: дотримуйтеся вашого поліса безпеки; вимірюйте пропускну здатність.
• Opportunistic locking / leasing: зазвичай підходить; але буря метаданих може поводитися дивно.
• Durable handles: корисні при повторних підключеннях клієнтів після коротких збоїв.

Права: «бекап може записувати, але не переписувати історію»

В ідеальному світі хост Windows створює нові набори бекапів, але не може видаляти чи змінювати старі. Досягти справжньої незмінності в SMB складно, але можна наблизитися:

• Використовуйте окремі підпапки для кожного хоста і кожного типу бекапу.
• Зробіть обліковий запис бекапу правом створення/запису у свою папку; обмежте видалення, де можливо.
• Використовуйте снапшоти NAS (щогодинні/щоденні) з політикою збереження. Снапшоти — ваш «undo».
• Якщо платформа підтримує — використовуйте WORM/іммутебельні снапшоти або блокування снапшотів.

DNS, NTP і сертифікати: нудні речі, які кусають

Якщо NAS і Windows мають різний час, або DNS повертає неправильну IP через застарілі записи, автентифікація SMB падає так, ніби це «мережеве дивне». Поставте NAS на той самий NTP-джерело, що й контролери домену (або щонайменше в межах розумного дрейфу) і трактуйте DNS-записи як продакшн-конфіг.

Налаштування на Windows: облікові дані, скрипти та розклад

Використовуйте Robocopy для файлових бекапів, але ставтеся до нього як до інструменту підвищеної потужності

Robocopy надійний і суворо чесний — якщо ви правильно читаєте його коди виходу. Ключові рішення:

• /MIR дзеркалить видалення (небезпечне, якщо вказано неправильно, корисне якщо ви для цього спроектували систему).
• /Z режим відновлення корисний при нестабільних лінках; /ZB може перейти в backup mode якщо дозволи дозволяють.
• /R та /W вирішують, чи чекати вічно на заблоковані файли (не варто).
• /COPY:DAT vs /COPY:DATSOU залежить від того, чи потрібно зберігати ACL і аудит.

Для більшості налаштувань backup→NAS ви копіюєте дані і часові мітки та ведете агресивний лог. Якщо вам потрібна точність ACL, треба протестувати відновлення і підтвердити, що NAS правильно їх зберігає.

Windows Server Backup до SMB: корисно, але майте на увазі його особливості

Windows Server Backup (WSB) може цілитися на віддалену спільну папку, але має обмеження: він керує власною структурою папок, не завжди зберігає декілька версій так, як ви очікуєте на шарі, і може поводитися інакше, ніж бекап на виділений диск. Використовуйте його, коли вам потрібен system state, bare-metal recovery або інтеграція VSS на Windows Server.

Task Scheduler: запускайте під сервісною ідентичністю, а не «коли я ввійшов»

Плановані бекапи мають працювати незалежно від того, чи хтось залогінений. Використовуйте виділений обліковий запис (доменний або локальний), встановіть «Run whether user is logged on or not» і збережіть облікові дані. Потім загартуйте цей обліковий запис. Це не місце для креативу.

Жарт №2: Нічого не старить вас швидше, ніж «успішний» бекап, який не відновлюється.

Практичні завдання (команди, виводи, рішення)

Це конкретні завдання, які ви можете виконати з Linux адміністративної машини, shell NAS або jump host. Кожне містить, що означає вивід і яке рішення з нього випливає. Використовуйте їх як стандартну операційну процедуру при діагностиці «випадкових збоїв».

Завдання 1: Перевірте стабільність DNS для імені NAS

cr0x@server:~$ dig +short nas01.corp.local
10.20.30.40

Значення виводу: Ви отримали один A-запис. Якщо бачите кілька IP, що змінюються, можливо ви стикаєтеся з round-robin, застарілими записами або плутаниною з мультигомованим NAS.

Рішення: Якщо IP нестабільний або невірний — виправте DNS спочатку. Не налаштовуйте SMB на рухомій цілі.

Завдання 2: Перевірте доступність і затримку (ICMP)

cr0x@server:~$ ping -c 5 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.512 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.488 ms
64 bytes from 10.20.30.40: icmp_seq=3 ttl=64 time=0.501 ms
64 bytes from 10.20.30.40: icmp_seq=4 ttl=64 time=0.497 ms
64 bytes from 10.20.30.40: icmp_seq=5 ttl=64 time=0.493 ms

--- 10.20.30.40 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4090ms
rtt min/avg/max/mdev = 0.488/0.498/0.512/0.010 ms

Значення виводу: Низька затримка і нема втрат. Якщо бачите втрати або спайки, SMB буде «випадково» зависати та перепідключатися.

Рішення: Якщо є втрата пакетів — припиніть звинувачувати Windows Backup. Виправте комутатори, Wi‑Fi, кабелі або перевантажені лінки.

Завдання 3: Підтвердіть доступність TCP 445 (SMB)

cr0x@server:~$ nc -vz 10.20.30.40 445
Connection to 10.20.30.40 445 port [tcp/microsoft-ds] succeeded!

Значення виводу: Порт відкритий. Якщо час очікування або відмова — у вас проблеми з фаєрволом або маршрутизацією.

Рішення: Якщо заблоковано — виправте політику мережі перед тим, як торкатися облікових даних або прав доступу.

Завдання 4: Перелічіть SMB-шари, щоб підтвердити, що узгодження працює

cr0x@server:~$ smbclient -L //10.20.30.40 -U 'CORP\backup_svc%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	backups         Disk      Windows backups
	IPC$            IPC       IPC Service (nas01)
SMB1 disabled -- no workgroup available

Значення виводу: Аутентифікація пройшла і шар існує. Рядок «SMB1 disabled» — це добре; це позитивний знак.

Рішення: Якщо перелік не вдається з NT_STATUS_LOGON_FAILURE — ви в зоні проблем з обліковими даними/ідентичністю, а не зі зберіганням.

Завдання 5: Перевірте, чи можете записати та прочитати тестовий файл на шарі

cr0x@server:~$ smbclient //10.20.30.40/backups -U 'CORP\backup_svc%REDACTED' -c 'mkdir _smb_test; cd _smb_test; put /etc/hosts hosts.txt; ls; get hosts.txt /tmp/hosts.txt; del hosts.txt; cd ..; rmdir _smb_test'
  hosts.txt                         A      173  Tue Feb  4 12:10:11 2026
getting file \_smb_test\hosts.txt of size 173 as /tmp/hosts.txt (28.2 KiloBytes/sec) (average 28.2 KiloBytes/sec)

Значення виводу: Створення/запис/читання/видалення пройшли успішно. Якщо видалення не вдається, але запис так — ваші «майже лише додавання» права можуть працювати (або бути некоректно налаштованими).

Рішення: Визначте, чи повинні бекапи мати право видаляти. Якщо ви використовуєте /MIR у Robocopy — право на видалення має велике значення.

Завдання 6: Виміряйте «чисту» пропускну здатність великим файлом (швидка перевірка реальності)

cr0x@server:~$ dd if=/dev/zero of=/tmp/backup_test.bin bs=16M count=256 status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2 s, 2.1 GB/s

cr0x@server:~$ time smbclient //10.20.30.40/backups -U 'CORP\backup_svc%REDACTED' -c 'put /tmp/backup_test.bin _perf/backup_test.bin'
real	0m39.214s
user	0m0.081s
sys	0m0.051s

Значення виводу: Якщо 4 GiB файл займає ~39 с — ви близько ~100–120 MB/s ефективно, що типово для 1GbE з урахуванням оверхеду. Якщо ~10 MB/s — щось не так.

Рішення: Якщо пропускна здатність низька — шукайте проблеми в мережі (дуplex, MTU), CPU NAS (підписування/шифрування) або швидкості запису дисків.

Завдання 7: Швидко перевірте стан дисків NAS (SMART summary)

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.0] (local build)
SMART overall-health self-assessment test result: PASSED

Значення виводу: «PASSED» необхідно, але недостатньо. Якщо воно провалене — припиніть: ви бекапите на помираючу ціль.

Рішення: Замініть несправні диски, потім перевірте статус відновлення масиву перед тим, як довіряти бекапам.

Завдання 8: Проінспектуйте ємність NAS і тиск на inode-и

cr0x@server:~$ df -h /mnt/backups
Filesystem      Size  Used Avail Use% Mounted on
tank/backups     40T   31T  9.0T  78% /mnt/backups

cr0x@server:~$ df -i /mnt/backups
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
tank/backups     20000000 8400000 11600000   43% /mnt/backups

Значення виводу: Достатньо місця й inode-ів. Якщо використання inode наближається до 100%, бекапи дрібних файлів зазнають поразки, навіть при наявності вільних ТБ.

Рішення: Якщо тиск на inode високий — скорегуйте політику збереження, консолідуйте дрібні файли (архівуйте) або використайте інший підхід до цього набору даних.

Завдання 9: Виявляйте обриви SMB-сесій, дивлячись логи (syslog NAS)

cr0x@server:~$ sudo tail -n 20 /var/log/samba/log.smbd
[2026/02/04 12:03:09.120145,  1] ../../source3/smbd/service.c:787(make_connection_snum)
  make_connection_snum: Connect path is '/mnt/backups' for service [backups]
[2026/02/04 12:05:44.772903,  1] ../../source3/smbd/sesssetup.c:157(auth3_check_password)
  check_ntlm_password:  Authentication for user [CORP]\[backup_svc] -> [backup_svc] FAILED with error NT_STATUS_WRONG_PASSWORD

Значення виводу: Маємо помилки аутентифікації під час з’єднання. Це не «випадково». Це ротація облікових даних, кешовані креденшали або кілька задач з різними паролями.

Рішення: Виправте управління обліковими записами: або координуйте ротацію з розкладом завдань, або використайте gMSA (якщо ви в домені і клієнт підтримує це).

Завдання 10: Підтвердіть, що Windows-хост може розв’язати й досягти NAS (з Linux jump host — перевірте ARP і маршрутизацію)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.20.30.1 dev eth0 src 10.20.30.50 uid 1000
    cache

Значення виводу: Маршрут чистий. Якщо трафік йде петлею через фаєрвол несподівано, ви помітите це тут.

Рішення: Якщо маршрутизація дивна — виправте її; SMB не любить асиметричну маршрутизацію та stateful фаєрволи з сюрпризами.

Завдання 11: Виміряйте проблеми MTU (виявлення «чорних дір»)

cr0x@server:~$ ping -c 3 -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
1480 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.605 ms
1480 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.598 ms
1480 bytes from 10.20.30.40: icmp_seq=3 ttl=64 time=0.602 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms

Значення виводу: Стандартний MTU працює без фрагментації. Якщо це падає в мережі з «включеними» jumbo frames — у вас може бути несумісний MTU, що спричиняє зупинки.

Рішення: Стандартизувати MTU по всьому шляху або вимкнути jumbo frames. Напівналаштовані jumbo — класичний генератор «випадкової пропускної здатності».

Завдання 12: Перевірте, що NAS не завантажений CPU під час SMB-передач

cr0x@server:~$ top -b -n 1 | head -n 12
top - 12:11:26 up 31 days,  4:22,  2 users,  load average: 6.21, 6.02, 5.44
Tasks: 214 total,   1 running, 213 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.4 us,  3.1 sy,  0.0 ni, 82.9 id,  0.2 wa,  0.0 hi,  1.4 si,  0.0 st
MiB Mem :  64384.0 total,   8120.5 free,  10212.0 used,  46051.5 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  53500.2 avail Mem

Значення виводу: CPU переважно в режимі idlе. Якщо під час передач спостерігається високе завантаження системного CPU (особливо зі шифруванням/підписуванням SMB), CPU NAS стає вузьким місцем.

Рішення: Якщо CPU перевантажений — розгляньте відключення SMB-шифрування в довіреній LAN, оновіть CPU NAS або перейдіть на 10GbE лише якщо CPU витримає навантаження.

Завдання 13: Підтвердіть стан ZFS pool/dataset (якщо застосовно)

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 09:12:33 with 0 errors on Sun Feb  2 03:10:22 2026
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0
	    sdc     ONLINE       0     0     0
	    sdd     ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0

errors: No known data errors

Значення виводу: Пул здоровий; scrub запущено; помилок немає. Якщо бачите checksum-помилки — ваша ціль бекапу може псувати дані.

Рішення: Якщо є помилки — перестаньте вважати NAS безпечним. Виправте апаратні проблеми, кабелі, прошивку HBA, пам’ять, потім повторно перевірте бекапи.

Завдання 14: Перелічіть снапшоти й підтвердіть політику збереження (якщо застосовно)

cr0x@server:~$ zfs list -t snapshot -o name,used,creation -s creation | tail -n 5
tank/backups@auto-2026-02-04_0800   1.2G  Tue Feb  4 08:00 2026
tank/backups@auto-2026-02-04_0900   1.1G  Tue Feb  4 09:00 2026
tank/backups@auto-2026-02-04_1000   1.3G  Tue Feb  4 10:00 2026
tank/backups@auto-2026-02-04_1100   1.2G  Tue Feb  4 11:00 2026
tank/backups@auto-2026-02-04_1200   1.4G  Tue Feb  4 12:00 2026

Значення виводу: Снапшоти виконуються регулярно. Якщо снапшотів нема — у вас нема «буфера» проти рансомваре або випадкового /MIR катастрофи.

Рішення: Якщо снапшоти відсутні — впровадьте їх перш ніж оголошувати систему бекапу «завершеною».

Завдання 15: Перевірте конфіг SMB-сервера на наявність слабких протоколів fallback (Samba)

cr0x@server:~$ testparm -s | egrep -i 'server min protocol|server max protocol|smb encrypt|server signing'
	server min protocol = SMB2_10
	server max protocol = SMB3_11
	server signing = mandatory
	smb encrypt = disabled

Значення виводу: Ви не дозволяєте SMB1. Підписування обов’язкове. Шифрування виключене (добре в довіреній LAN; небажано в незахищених мережах).

Рішення: Якщо min protocol = SMB1 — змініть це. Якщо потрібне шифрування — увімкніть і повторно виміряйте CPU і пропускну здатність.

Завдання 16: Підтвердіть, що шлях шару не на повільному файловому рівні

cr0x@server:~$ mount | grep backups
tank/backups on /mnt/backups type zfs (rw,xattr,noacl)

Значення виводу: Ви на потрібному dataset. Якщо бекапи потрапляють на невеликий OS-том або кеш-пристрій випадково — ви знайшли причину «випадкового» закінчення місця.

Рішення: Переконайтеся, що шляхи шару мапляться на dataset/том з правильними квотами і політикою снапшотів.

Швидкий план діагностики

Це версія для випадку «хтось чекає на дзвінок». Мета — визначити вузьке місце за хвилини, а не години.

Перше: це розв’язання імен, маршрутизація чи доступ до порту?

• Перевірте DNS для імені NAS (Завдання 1).
• Зробіть ping і шукайте втрати/спайки затримки (Завдання 2).
• Підтвердіть доступність TCP 445 (Завдання 3).

Якщо будь-яке з цих не працює: це інфраструктурна/мережна проблема. Не витрачайте час на ротацію паролів або налаштування Robocopy.

Друге: це автентифікація чи авторизація?

• Перелічіть шари і пройдіть аутентифікацію (Завдання 4).
• Запишіть/прочитайте тестовий файл (Завдання 5).
• Перевірте логи Samba на NAS щодо відмов у вході (Завдання 9).

Якщо ви можете перелічити шари, але не можете записати: проблема в правах. Якщо запис працює іноді, але ні після зміни пароля — гігієна облікових даних.

Третє: це продуктивність (CPU NAS, диск або MTU мережі)?

• Швидкий тест пропускної здатності великим файлом (Завдання 6).
• Перевірка MTU (Завдання 11).
• Завантаження CPU NAS під час передачі (Завдання 12).
• Стан дисків і пулу (Завдання 7 і 13).
• Ємність/inode-тисок (Завдання 8).

Правило: Якщо великий файл передається добре, але бекапи повільні — проблема в метаданих/дрібних файлах, антивірусі або надміру паралельних задач. Якщо великі файли повільні — проблема в каналі або шляху запису NAS.

Четверте: це планування і накладання?

Це прихована відмова. Завдання працюють довго, наступний запуск стартує, сесії конфліктують, блокування зростають, і ви отримуєте часткові бекапи. Аудитуйте розклади й переконайтеся, що на хості одночасно активне лише одне завдання, якщо ви не довели, що конкуренція працює.

Типові помилки: симптом → корінь → виправлення

1) Симптом: «Видає access denied, але тільки на деяких папках»

Корінь: Обліковий запис бекапу не має прав до захищених шляхів, або UAC/token filtering змінює поведінку між інтерактивним запуском і запланованим.

Виправлення: Використайте виділений сервісний обліковий запис; явно надайте йому права читання на потрібні дерева; тестуйте під тією ж ідентичністю, яку використовує планувальник. «Працює, коли я запускаю як адмін» — це не тест; це зізнання.

2) Симптом: «Robocopy каже успіх, але файлів немає»

Корінь: Ігнорували коди виходу Robocopy і підсумкові рядки; файли пропускалися через довжину шляху, junction-і, заблоковані файли або виключення.

Виправлення: Парсіть коди виходу; фіксуйте задачі при наявності пропущених/неуспішних файлів; увімкніть логування; визначте політику щодо junction-ів (/XJ) і довгих шляхів (увімкніть long paths у політиці Windows, де потрібно).

3) Симптом: «Бекап на NAS рандомно повільний, іноді нормальний»

Корінь: MTU mismatch, Wi‑Fi-лінки, енергозберігаючі налаштування NIC, CPU-навантаження від підписування/шифрування SMB, або конкуренція задач, що викликає контеншн по дискам NAS.

Виправлення: Стандартизувати MTU; використовувати дротові лінки для серверів; виміряти CPU NAS; рознести розклади; обмежити потоки Robocopy; розглянути виділений NIC/VLAN для бекапів.

4) Симптом: «Працювало місяцями, потім почало падати після ротації паролів»

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

Виправлення: Впровадьте gMSA де можливо; інакше координуйте ротацію облікових даних і оновіть усі планові задачі одночасно. Перевірте логи аутентифікації NAS.

5) Симптом: «На NAS є місце, але бекапи падають з ‘no space left’»

Корінь: Резерв для снапшотів, квоти або вичерпання inode-ів. Або шар вказує на менший том, ніж ви думаєте.

Виправлення: Перевірте df -h і df -i (Завдання 8), квоти і шлях, на який вказує шар (Завдання 16). Підкорегуйте збереження; розширіть dataset; не вважайте 90% заповненості «достатньо».

6) Симптом: «WSB до мережевого шару зберігає лише одну версію / дивно перезаписує»

Корінь: Поведінка WSB щодо віддалених шарів відрізняється від виділених дисків; воно керує версіями по-іншому і може не підтримувати історію, яку ви очікуєте.

Виправлення: Використовуйте WSB на виділений диск або iSCSI-ціль, якщо вам потрібне коректне збереження версій, або покрийте це снапшотами NAS, щоб версії існували на шарі зберігання.

7) Симптом: «Бекапи зупиняються під час передачі, потім відновлюються, потім корумпуються»

Корінь: Нестабільна мережа, обриви SMB-сесій або проблемний NIC/драйвер. Іноді «корисні» фаєрволи для інспекції скидають сесії.

Виправлення: Перевірте втрати і логи (Завдання 2 та 9). Відключіть проблемні NIC offloads на Windows (протестуйте) і прибирайте stateful middleboxes з шляху бекапів, де це можливо.

8) Симптом: «Рансомваре зашифрував бекапи на NAS теж»

Корінь: Облікові дані бекапу мали права на видалення/зміну; бекапи були просто ще одним записуваним шаром; відсутня політика незмінності снапшотів.

Виправлення: Нашаровуйте захист: права найменших привілеїв для облікового запису бекапу, снапшоти з ретеншном (і immutability/locking якщо підтримується), сегментація мережі і хоча б одна офлайн/офсайт копія. Просто доступний для запису SMB-шар — це не захист.

Контрольні списки / покроковий план

Фаза 1: Побудуйте ціль NAS, що працює передбачувано

1. Створіть виділений dataset/том для бекапів (окремо від шарів користувачів).
2. Увімкніть регулярні снапшоти (щогодини + щодня — типовий варіант; підлаштуйте під бізнес-потреби).
3. Створіть виділений SMB-шар (наприклад, backups) що вказує тільки на цей dataset.
4. Вимкніть SMB1; вимагайте SMB2+.
5. Визначте підписування/шифрування згідно політики безпеки; виміряйте CPU headroom.
6. Створіть виділений обліковий запис бекапу (CORP\backup_svc або локальний користувач NAS).
7. Налаштуйте права так, щоб аккаунт міг записувати у свою ціль, але не міг легко знищити історію.
8. Налаштуйте квоти/оповіщення, щоб «NAS майже повний» став тикетом, перш ніж це перетвориться на відмову.

Фаза 2: Побудуйте завдання Windows, що не брешуть

1. Виберіть метод бекапу для кожного навантаження:
   • Robocopy для файлового рівня (добрий дефолт).
   • WSB для system state / bare metal (для серверів).
2. Напишіть скрипт, що логгуватиме в стабільний локальний шлях і на NAS (якщо доступний).
3. Змушуйте задачу падати при ненульових/небажаних кодах виходу, а не «за відчуттями».
4. Заплануйте в Task Scheduler під виділеною ідентичністю.
5. Рознесіть розклади по вузлах, щоб уникнути NAS-штампу опівночі.
6. Проведіть вправу з відновлення на непро-дукційному хості. Заміряйте час. Документуйте.

Фаза 3: Оперціоналізуйте (те, що люди пропускають)

1. Відправляйте логи в централізоване місце (навіть інший шар або збирач логів).
2. Піднімайте оповіщення про помилку, але також про «завдання не запустилося» і «завдання працювало в 2× довше».
3. Щомісяця: перевірка наявності снапшотів і відповідності ретеншну.
4. Щоквартально: вправа з відновлення для принаймні одного репрезентативного хоста.
5. Після будь-якого оновлення прошивки NAS: перезапустіть тести пропускної здатності і автентифікації.

Три міні-історії з практики

Інцидент через хибне припущення: «Це файл-шар, отже все ок»

Середня компанія перейшла з USB-дисків для бекапів на блискучий NAS. План був простий: створити один шар, надати «Domain Admins» повні права і вказати на нього планові Robocopy з усіх Windows-серверів. Вони назвали це централізованими бекапами. Централізовано — так.

Хибне припущення було тонким: вони вважали, що семантика SMB уніфікована на всіх пристроях і що «повні права» запобіжать проблемам з правами. Насправді кілька серверів мали довгі шляхи і junction-и в кешах додатків. Robocopy пропускав деякі шляхи, логував попередження, повертав код, що не був «0», а обгортковий скрипт все одно відправив лист «SUCCESS», бо перевіряв лише наявність файлу логу.

Провал проявився під час запиту на відновлення: «бекап» одного сервера не включав ту одну важливу директорію. Не тому, що NAS впав, а тому, що копіювання тихцем було неповним місяцями.

Виправлення не було екзотичним. Вони написали справжню перевірку кодів виходу, зробили політику обробки junction-ів явною (/XJ в деяких місцях, включати там, де потрібно), увімкнули довгі шляхи там, де доцільно, і додали щотижневий вибірковий тест відновлення. NAS не змінювався. Правда їхнього процесу — так.

Оптимізація, що відпалила: «Увімкнемо усі фічі швидкості»

Інша організація мала скарги на продуктивність: бекапи заходили в робочі години. Хтось увімкнув jumbo frames на NIC NAS і ввімкнув SMB-шифрування «за відповідністю», думаючи, що сучасне залізо витримає.

В тесті це працювало: один великий файл копіювався швидко з одного хоста. Потім почалися нічні бекапи. Під конкуренцією CPU NAS підскочив через шифрування і підписування, а один проміжний комутатор мав неправильно налаштовані jumbo. Деякі клієнти зависали, перепідключалися, потім продовжували — але поведінка перепідключення була неузгодженою між версіями Windows і драйверами NIC.

Результат виглядав як випадковість: деякі хости вдавалися, деякі падали, деякі працювали 8 годин замість 2. Кількість тикетів зросла. Люди почали сперечатися, в якій фазі місяця краще робити бекапи.

Рішення виявилося нудне: повернути MTU до 1500 всюди (поки не гарантовано end-to-end jumbo), тримати підписування згідно політики, селективно вимкнути шифрування на довіреному VLAN для бекапів і обмежити конкуренцію. Бекапи знову завершувалися до світанку. Продуктивність прийшла від узгодженості, а не героїчних переключень.

Нудно, але правильно, що врятувало день: снапшоти + мінімальні привілеї

Третє середовище зробило дві «нецятливі» речі з самого початку: шар бекапу жив на власному dataset з годинними снапшотами, а обліковий запис бекапу міг записувати нові дані, але не мав широких прав на видалення. Це не була ідеальна незмінність, але значно складніше було зруйнувати історію.

Їх все ж вразив рансомваре на робочій станції з доступом до деяких загальних шарів. Шкідливе ПЗ спробувало пройти мережею й зашифрувати все, що записувалося. Воно дісталося до NAS, знайшло шар бекапу і завдало шкоди — обмежену.

Що їх врятувало — не якийсь магічний продукт кінцевої точки. Це був останній нічний снапшот у цілості, і шкідливе ПЗ не могло легко видалити історію снапшотів. Шлях відновлення був ясним: відкотити уражений dataset до відомого доброго снапшоту, потім відновити клієнтів.

Постмортем був майже нудним, що є найвищою похвалою в операціях. Їхня «зайва» робота зі снапшотами й правами перетворила потенціальну катастрофу на виснажливий, але рутинний вікенд.

Питання й відповіді

1) Чи варто використовувати вбудований Windows «Backup and Restore (Windows 7)» до NAS?

Можна, але це застаріло і дивно поводиться. Для сучасних налаштувань віддавайте перевагу Robocopy для файлового рівня, а Windows Server Backup — для серверних образів / system state, якщо вам конкретно потрібен такий робочий процес.

2) Чи обов’язкове SMB signing і чи сповільнить це бекапи?

Багато корпоративних політик вимагають цього. Так, це може зменшити пропускну здатність на слабших CPU NAS або при багатьох паралельних потоках. Вимірюйте до і після, і слідкуйте за CPU NAS під час передач.

3) Чи варто увімкнути SMB-шифрування?

Якщо трафік бекапу переходить незахищеними мережами або інфраструктурою, якою ви не керуєте, шифрування має сенс. На виділеному довіреному VLAN у дата-центрі воно може бути опціональним. Якщо увімкнете — перетестуйте пропускну здатність і CPU headroom.

4) Чи потрібен VSS, якщо я просто копіюю файли?

Якщо ви копіюєте бази даних, PST-файли або будь-що, що залишається відкритим і змінюється під час бекапу, потрібен підхід, усвідомлений додатком. Robocopy сам по собі може скопіювати незграбні версії живих файлів. Використовуйте VSS-aware інструменти або нативні методи бекапу для таких навантажень.

5) Чи використовувати /MIR у Robocopy?

Тільки коли ви абсолютно впевнені у цільовому шляху і маєте захист снапшотами на NAS. /MIR видалить файли на цілі, яких немає на джерелі. Один раз вказати неправильно — і ви дізнаєтеся, що таке адреналін.

6) Як зберігати кілька версій, якщо Robocopy дзеркалить зміни?

Використовуйте снапшоти NAS для версіонування або реалізуйте ротацію у файловій структурі (папки за датою) і чистку за політикою. Снапшоти зазвичай найчистіший шар версіювання для NAS.

7) Як зрозуміти, що бекапи відновлюються?

Відновлюючи. Як мінімум: оберіть один хост на квартал, відновіть репрезентативний набір даних в ізольоване середовище і перевірте запуск додатку або цілісність файлів. Логи — не доказ відновлюваності; відновлення — доказ.

8) Який найкращий спосіб захистити NAS-бекапи від рансомваре?

Накладайте шари: мінімальні привілеї для облікових записів бекапу, снапшоти з ретеншном (і immutability/locking, якщо підтримується), сегментація мережі і принаймні одна офлайн/офсайт копія. Просто записуваний SMB-шар не є захистом.

9) Мої бекапи повільні тільки на дрібних файлах. Чому?

Дрібні файли — вектори для метаданих: багато звертань до директорій, перевірок ACL і SMB round trip-ів. Покращуйте це швидшими дисками/SSD для метаданих, більше RAM, менше паралельних задач і реалістичні очікування. Також виключіть непотрібні кеші і збірки з бекапів.

10) Чи можна використовувати один шар для всіх серверів?

Можна, але не варто, якщо у вас немає суворих субпапкових прав і квот. Один шар має тенденцію перетворюватися на «пастку» з бійками за ретеншн і випадковими перезаписами. Розділяйте щонайменше за хостом або середовищем.

Наступні кроки, щоб це прижилося

1. Визначте метод бекапу під навантаження: Robocopy для файлового рівня, WSB для system state / bare metal.
2. Побудуйте ціль NAS правильно: виділений dataset, снапшоти, SMB2/3 тільки, розумні права.
3. Стандартизуйте ідентичність: один сервісний аккаунт бекапу, протестований у тому ж контексті, що і Task Scheduler.
4. Інструментуйте і налаштуйте оповіщення: коди виходу, парсинг логів, «не запустилося» і «працювало надто довго».
5. Проведіть вправу з відновлення і зафіксуйте кроки, поки ще свіжо і трохи незручно.

Якщо ви зробите тільки одну річ цього тижня: впровадьте снапшоти і перевірте відновлення. Усе інше — оптимізація; ці дві речі — виживання.