Time Machine через SMB: налаштування мережевого бекапу на macOS

Time Machine – штатний механізм резервного копіювання в macOS, який уміє писати бекапи на мережеве сховище через SMB. У такій схемі Mac зберігає копію в окремий share на NAS або сервері. Time Machine через SMB на macOS працює нормально, якщо сервер стабільно тримає сесію, а перший великий цикл запускається не по слабкому Wi‑Fi.

Робоча схема проста: стабільний SMB-сервер, окремий share під один Mac або під окремі квоти, дротова мережа для стартового копіювання і сховище, яке не засинає посеред запису. Якщо чекати від цього тієї ж передбачуваності, що від локального SSD або USB-диска, проблеми зазвичай починаються на першому великому бекапі.

Коли SMB-схема доречна

Такий варіант має сенс для домашнього NAS, mini server або окремого файлового сервера в LAN. Схема добре працює, коли Mac регулярно бачить той самий share, а сховище не перевантажене контейнерами, медіатекою чи іншими довгими записами.

Найкращий сценарій – один або кілька Mac у домашній мережі, Ethernet для першого циклу і окремий диск або RAID під резервні копії. Для ноутбука це теж зручно: повертається в ту саму мережу, знаходить знайомий ресурс і продовжує інкрементальний бекап.

Гірше працює стара коробка з повільними дисками, слабкий Wi‑Fi і share на універсальному сервері, де паралельно крутяться торенти, контейнери й індексація файлів. У такій схемі стартовий цикл легко розтягується на добу, а потім обривається через дрібну помилку сесії.

Де цей варіант виправданий

Мережевий бекап доречний, коли зовнішній диск не підключений постійно, а NAS і так працює цілодобово. Ще один нормальний випадок – кілька комп’ютерів у квартирі, яким простіше видати окремі квоти на одному сховищі.

Коли краще одразу вибрати інший підхід

Якщо перший цикл доведеться гнати тільки по Wi‑Fi, а даних уже сотні гігабайт, затримки й повторні спроби майже гарантовані. Якщо сервер часто засинає, перезавантажується або підіймається з затримкою, спочатку треба стабілізувати його доступність, наприклад через Wake-on-LAN для домашнього сервера.

Яке сховище підходить під цей бекап

macOS потрібен SMB-сервер, який коректно віддає мережеву папку, підтримує запис великих файлів і не рве сесію під навантаженням. Підійде NAS, Linux-сервер із Samba або готова система з підтримкою Time Machine over SMB.

Критичні вимоги тут прості: стабільний диск, достатньо вільного місця, передбачувані права доступу і нормальна мережа. Для стартового копіювання вузьким місцем часто стає не SMB, а повільний HDD або агресивне енергозбереження дисків. Якщо сховище збирається окремо, краще одразу закласти нормальний накопичувач. Для сервера з кешем або віртуалізацією окремо стане в пригоді матеріал про NVMe SSD для домашнього сервера.

Проста папка по SMB тут не підходить. Share має бути окремим, без ручного редагування вмісту з інших клієнтів. Time Machine створює власну структуру даних і погано переживає сторонні зміни всередині бекапу.

Що бажано мати на боці NAS або сервера

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

Підготовка share: квота, права і окремий користувач

Для Time Machine через SMB на macOS потрібен окремий share з правом запису для конкретного облікового запису. Загальну папку з документами або медіафайлами брати не варто. Окремий ресурс спрощує права, квоту і діагностику.

Найнадійніша схема – один share на один Mac або одна папка на кілька Mac з різними квотами, якщо NAS це підтримує. Квота потрібна не лише для економії місця. Вона не дає одному комп’ютеру зайняти весь обсяг і зламати бекапи інших клієнтів.

Права доступу краще тримати простими: окремий користувач, повний запис у свій share, без анонімного доступу і без змішаних ACL, які тягнуться зі старих каталогів. Пароль теж краще без екзотики, якщо NAS має слабку веб-панель або стару Samba. Циклічний запит пароля часто починається саме тут, а не в macOS.

Мінімальна логіка підготовки

1. Створити окремого користувача для бекапу.
2. Створити окремий share тільки під Time Machine.
3. Дати цьому користувачу повний доступ на запис.
4. Увімкнути квоту, якщо NAS або файлова система її підтримує.
5. Перевірити, що інші клієнти не монтують цю папку для ручної роботи.

Що ламає бекап найчастіше

Проблеми починаються, коли share лежить усередині каталогу з уже успадкованими ACL, а потім до нього додають ще й локальні дозволи файлової системи. Ще одна типова пастка – один і той самий обліковий запис для всіх сервісів NAS. Після зміни пароля macOS продовжує носити старі дані з Keychain і ходить по колу.

Як підключити мережеву папку в macOS

Спочатку share треба змонтувати в Finder, а вже потім вибрати його як ціль у Time Machine. Якщо macOS бачить SMB-папку, дозволяє запис і зберігає облікові дані в Keychain, далі процес стандартний.

1. У Finder відкрити Go - Connect to Server.
2. Ввести адресу на кшталт smb://nas.local/TimeMachine або smb://<server-ip>/TimeMachine.
3. Увійти під окремим користувачем для бекапу.
4. Поставити збереження пароля в Keychain.
5. Відкрити налаштування Time Machine і вибрати змонтований share як Backup Disk.

Якщо графічний інтерфейс не підхоплює ресурс одразу, допомагає простий тест: створити на share звичайний файл і видалити його. Так швидко видно, чи справді є запис, а не тільки читання. Після цього Time Machine зазвичай вже коректно пропонує папку.

Шукати тут CLI-магію сенсу мало. Поки Finder не відкриває smb:// без повторних логінів і зависань, стабільного бекапу не буде.

Що робити з першим великим бекапом

Перший цикл краще запускати по Ethernet і в час, коли NAS нічим більше не зайнятий. Для ноутбуків зручний окремий дротовий старт, а вже потім інкрементальні копії можуть іти по Wi‑Fi. Це прибирає значну частину випадкових збоїв.

Якщо потрібен локальний варіант замість мережевого, окремий зовнішній диск часто простіший. Підійде навіть проста збірка через USB-SATA адаптер для окремого диска бекапів.

Що перевірити після першого резервного копіювання

Після завершення першого циклу треба дивитися не тільки на статус Backup completed. Перевірка має охоплювати повторне підключення share, доступність файлів і наступний інкрементальний запуск. Багато конфігурацій проходять перший запис, а валяться вже на другому або третьому проході.

1. Переконатися, що Time Machine показує дату останнього успішного бекапу.
2. Відмонтувати share і змонтувати його знову без повторного введення пароля.
3. Запустити ще один бекап вручну після невеликої зміни файлів.
4. Перевірити, що NAS не переводить диск у sleep занадто агресивно.
5. Подивитися, чи не впирається share в квоту раніше, ніж очікувалося.

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

Який результат вважати нормальним

Нормальна поведінка така: Mac без ручних дій знаходить той самий share, пароль не питає, новий бекап стартує сам і закінчується без повідомлень про перевірку або повторну ініціалізацію. Якщо після сну ноутбука або ребута NAS усе це доводиться налаштовувати наново, конфігурація ще сира.

Чому система просить пароль по колу або не бачить share

Найчастіше причина в правах доступу, зламаному записі в Keychain або в самому SMB-share, який відкривається тільки на читання. Якщо папка монтується нестабільно, Time Machine або не покаже її взагалі, або почне без кінця просити логін і пароль.

Почати краще з простого: видалити старий запис для цього сервера з Keychain, відмонтувати share, змонтувати його заново і перевірити запис звичайного файла. Якщо цикл авторизації залишився, проблема майже напевно на боці сервера: пароль, ACL, ім’я користувача, гостьовий доступ або старий SMB-профіль.

Що перевірити по черзі

1. Чи правильна адреса ресурсу: smb://hostname/share.
2. Чи немає в Keychain кількох різних паролів для того самого NAS.
3. Чи може цей користувач створювати і видаляти файли в share.
4. Чи не вмикається гостьовий доступ замість авторизованого.
5. Чи не змінився hostname або IP сервера після ребута роутера.

Коли проблема в DNS або імені сервера

Якщо share іноді відкривається по імені, а іноді тільки по IP, краще вибрати один спосіб і не змішувати їх. macOS може зберегти одні креденшали для nas.local, а інші – для 192.168.1.10. Збоку це виглядає так, ніби пароль правильний, але система знову його просить.

Чому перший цикл іде дуже довго або обривається

Початковий бекап через мережу часто впирається в Wi‑Fi, повільний диск на NAS, sleep дисків або короткі обриви лінка. Для великих обсягів даних це очікувано. Неочікувана поведінка – коли копіювання регулярно стартує заново або зависає на тих самих етапах.

Головний підозрюваний – бездротова мережа. Навіть хороший Wi‑Fi дає стрибки затримки, а довге копіювання цього не любить. Другий кандидат – енергозбереження сховища: диск заснув, NAS прокинувся з затримкою, SMB-сесія померла, macOS почала повторювати операції. Зовні це виглядає як дуже довге зависання.

Часто проблема сидить і в самому диску на сервері. Якщо backup share лежить на випадковому USB-HDD, вузьким місцем стає вже не мережа. До певного масштабу це ще терпимо, але на великій бібліотеці фото або VM перший цикл перетворюється на довгу серію повторів і таймаутів.

Що допомагає скоротити час стартового копіювання

1. Підключити Mac до Gigabit Ethernet.
2. На час стартового бекапу вимкнути важкі задачі на NAS.
3. Перевірити, що share лежить на диску без агресивного sleep.
4. Тримати ноутбук на зарядці і без переходу в сон.
5. Переконатися, що на сховищі достатньо вільного місця з запасом.

Коли обриви викликає живлення

Якщо збої збігаються з короткими просадками живлення або перезапусками NAS, проблема вже не в SMB. Довгі резервні копії погано переживають навіть короткий power event. Для домашнього сервера це сильний аргумент на користь UPS, особливо коли сховище працює без нагляду.

Коли локальний диск кращий за мережевий share

Time Machine через SMB на macOS краще відкласти, якщо потрібне швидке відновлення, стабільність без мережевих умовностей або резервне копіювання дуже великої бібліотеки даних. У таких випадках локальний диск по USB або Thunderbolt зазвичай дає менше проблем.

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

Якщо даних багато, а мережеве сховище вже зайняте іншими сервісами, ролі краще рознести. Один диск або том – під бекапи, інший – під файли й контейнери. Інакше автоматичне резервне копіювання швидко починає залежати від чужого навантаження, sleep-політик і перезапусків сервера.

Офіційні деталі про Time Machine і сумісність macOS з мережевими цілями зібрані в документації Apple.

Коментарі

Коментарів ще немає. Обговорення - у Telegram.

Коментувати в Telegram