Офісному файловому ресурсу й загальнодоступному застосунку бронювання потрібні різні машини, бюджети та плани відновлення. Вирішуючи, як зібрати сервер, почніть із роботи, яку він має забезпечувати. Збірка з нуля означає вибір і встановлення сумісних компонентів, а потім встановлення операційної системи й налаштування робочого сервісу.
Для локальних документів розумною покупкою може бути тиха баштова система. Для доступного з інтернету застосунку оренда дозволяє уникнути роботи з обладнанням і приміщенням. В обох випадках потрібен відповідальний за доступ, оновлення та відновлення.
Перед роботою з обладнанням підготуйте посібники компонентів, вільну робочу поверхню та рекомендований виробником антистатичний захист. Для налаштування потрібні дротова мережа, інсталяційний USB-носій, локальні клавіатура й монітор, особистий обліковий запис адміністратора та другий комп’ютер для перевірки. Перед зміною розмітки дисків скопіюйте наявні дані в інше місце.
Визначте бізнес-завдання до вибору обладнання
Спільній папці з рахунками потрібні місткість і надійний доступ до файлів; публічний застосунок додає зовнішнє підключення та підтримку застосунку. Опишіть завдання, перш ніж підбирати серверне обладнання під вигідну пропозицію процесора чи RAM.
Складіть короткий перелік вимог:
- Назвіть сервіс і застосунки, які ним користуватимуться. Перелічіть одночасні дії, наприклад відкриття документів під час резервного копіювання.
- Виміряйте поточний обсяг даних, очікуване зростання та збережені версії. Відокремте потрібну бізнесу корисну місткість від суми обсягів на етикетках накопичувачів.
- Позначте доступ як суто офісний або публічний. Врахуйте сканери, принтери та інші локальні пристрої, яким потрібен доступ.
- Задайте допустиме вікно втрати даних, тобто цільову точку відновлення (RPO), і допустимий час відновлення сервісу, тобто цільовий час відновлення (RTO).
- Призначте адміністратора та заміну на час відсутності. Зафіксуйте бюджет купівлі й регулярних експлуатаційних витрат.
Сама кількість працівників не визначає потрібну потужність. Репрезентативний набір файлів та одночасних завдань дасть кращу приймальну перевірку.
Порівняйте збірку, купівлю та оренду
Баштовий сервер біля офісного комутатора забезпечує локальне передавання файлів навіть без інтернету, якщо локальна мережа й живлення працюють. Оренда переносить обладнання на інший майданчик і робить офісний доступ залежним від WAN-з’єднання. Відповідальність розподіляється так.
| Варіант | Збірка та власність | Інфраструктура майданчика | Інтеграція й підтримка | ОС, застосунки, доступ і відновлення |
|---|---|---|---|---|
| Самостійна збірка з компонентів | Ви вибираєте, збираєте та володієте компонентами | Ви забезпечуєте живлення, охолодження й мережу | Ви вирішуєте питання сумісності; гарантії компонентів окремі | Ви адмініструєте сервіс і створюєте резервні копії |
| Купівля готової або відновленої системи | Постачальник збирає; машина належить вам | Ви надаєте майданчик і мережу | Підтримка системи залежить від фактичної гарантії та договору | Ви адмініструєте, якщо це не покриває окрема послуга |
| Оренда виділеного сервера | Провайдер надає цілий фізичний сервер | Провайдер обслуговує майданчик розміщення | Заміна обладнання та строки реагування залежать від договору | За самостійного керування ОС, застосунки й відновлення залишаються вашою відповідальністю |
| Оренда VPS | Провайдер виділяє ресурси на хості | Провайдер обслуговує фізичну інфраструктуру | Підтримка хоста відрізняється від підтримки всередині вашого VPS | За самостійного керування гостьова ОС, застосунки й відновлення залишаються вашою відповідальністю |
Вибирайте самостійну збірку, коли корисна гнучкість компонентів і є фахівець, здатний діагностувати всю машину. Готова система з підтримкою доречна, коли єдиний процес ремонту постачальника виправдовує доплату. Перед купівлею відновленого обладнання перевірте підтримку прошивки, зношення дисків, наявність кошиків і кабелів, шум, споживання енергії та письмову гарантію.
Для оренди вибір між VPS і виділеним обладнанням визначають ресурси та ізоляція. Невеликому застосунку може вистачити VPS; постійні високі потреби чи контроль обладнання можуть виправдати виділений сервер. Фізичні ядра й vCPU VPS не є взаємозамінними обіцянками потужності.
Розгляньте VPS до рішення про власноручну збірку

Купівля обладнання вимагає витрат до того, як стане зрозумілою поведінка навантаження. Самостійна збірка додає перевірку сумісності та монтаж. Готова система прибирає цей етап, але все одно потрібні місце, живлення, охолодження й план на випадок відмов обладнання. Для сайту, застосунку чи тестового середовища, які не мусять працювати в офісі, оренда дозволяє почати швидше та визначити реальні потреби.
Наші тарифи Linux VPS пропонують RAM DDR5, швидке сховище NVMe та підключення через канали хоста 40 Гбіт/с. Для навантажень, що потребують виділеної потужності vCPU, наші тарифи High Performance резервують її для вашого віртуального сервера. Ви отримуєте потужну інфраструктуру без купівлі обладнання чи розміщення публічного сервісу через офісне інтернет-з’єднання.
Ви також зберігаєте контроль над ПЗ. Наші VPS некеровані й надають повний root-доступ через SSH. Ви самі вибираєте ОС, встановлюєте застосунки й налаштовуєте сервіси. Оновлення, безпека та резервні копії залишаються вашою відповідальністю, даючи практичний досвід адміністрування, потрібний власному серверу.
Погодинна оплата дозволяє почати з невеликого набору ресурсів. На тарифах PAYG можна змінювати ресурси з панелі керування зі зміною потреб, а безкоштовний моніторинг допомагає стежити за використанням. Наша 14-денна гарантія повернення коштів дає новим клієнтам два тижні на оцінку послуги й запит повернення за умовами гарантії, якщо вона не підійшла.
Оренда не закриває шлях до власного обладнання. Якщо згодом ви зберете фізичний Linux-сервер, можна перевстановити програмний стек, перенести файли й експорти баз даних, адаптувати конфігурацію та все перевірити до перемикання. Набутий досвід керування VPS стане в пригоді під час переходу.
Підберіть конфігурацію під навантаження
Офісні файли та спільні документи
Припустімо, є приблизно 2 ТБ звичайних документів із локальним доступом через дротовий Ethernet. Почніть планування з тихої баштової системи із сучасним CPU на 4–6 ядер, 32 ГБ підтримуваної RAM, завантажувальним SSD 500 ГБ і двома HDD по 4 ТБ у програмному дзеркалі Linux RAID1 для даних. До накладних витрат файлової системи й резервування дзеркало дає приблизно початкову місткість одного диска 4 ТБ. Завантажувальний SSD залишається єдиною точкою відмови.
Використовуйте гігабітний Ethernet на сервері, комутаторі й клієнтах і сумісний ДБЖ. Передбачте окремий знімний диск 8 ТБ для копій і незалежно захищену копію поза майданчиком. Версії та зростання файлів можуть перевищити місткість диска; виміряйте обсяг змін і збережених копій. Ця схема не обіцяє пропускної здатності для відеомонтажу.
Ілюстративний бюджет 1 200–1 800 доларів США включає обладнання, ДБЖ і локальні резервні копії. Податки, праця, ліцензії та плата за зберігання поза майданчиком виключені. Подальша інсталяція реалізує цей сценарій офісних файлів.
Публічний сайт або невеликий застосунок
Припустімо невелику базу даних і помірну медіаколекцію з початковим робочим обсягом менш як 20 ГБ. Оцініть типову оренду 2–4 vCPU, 4–8 ГБ RAM і SSD 80–160 ГБ із запасом для ОС, журналів і зростання. Ці ресурси потребують навантажувального тесту конкретного застосунку й не визначають місткість відвідувачів.
Фізична альтернатива може мати сучасний CPU на 4–6 ядер, 16 ГБ RAM і один SSD 500 ГБ; після форматування та ОС корисний обсяг менший за вказаний. Резервування дисків немає. У гіпотетичний бюджет обладнання 800–1 400 доларів США включіть дротове підключення, ДБЖ і незалежне місце копій, із тими самими виключеннями, що вище.
Публічний хостинг з офісу також потребує належної вихідної пропускної здатності, адресації та умов провайдера. Сплануйте оновлення, доступність живлення й підтримку застосунків. Це окреме рішення про розгортання; налаштування файлового ресурсу нижче не встановлює публічного вебстека.
Окремі внутрішні сервіси й тестові середовища
Припустімо кілька ізольованих сервісів із сумарними активними даними менш як 400 ГБ. Приклад хоста має сучасний восьмиядерний CPU, 64 ГБ сумісної RAM і дзеркальні SSD по 1 ТБ, з окремим завантажувальним пристроєм, якщо він потрібен платформі. Це приблизно 1 ТБ початкової місткості до накладних витрат; кожен гостьовий диск використовує спільний пул.
Виділіть гостям 8 + 8 + 16 ГБ RAM і ще 8 ГБ хосту та сховищу: призначено 40 ГБ, залишається 24 ГБ. Це відповідає обліку хоста й гостей у вимогах Proxmox, але не доводить продуктивності CPU чи допустимої щільності гостей. Перевірте VT/AMD-V, драйвери й гостьові ліцензії; для передавання пристроїв важлива підтримка IOMMU. Не використовуйте ZFS поверх апаратного RAID.
Використовуйте дротову мережу, ДБЖ і незалежні гостьові резервні копії. Гіпотетичний бюджет 1 800–3 000 доларів США включає обладнання, ДБЖ і локальне копіювання, але виключає податки, ліцензії, працю й зберігання поза майданчиком. Віртуалізація серверів розділяє гостьові середовища; один фізичний хост залишається єдиною точкою відмови.
Виберіть сумісні серверні компоненти

Процесор може підходити до сокета, але потребувати іншої версії BIOS для запуску плати. Створіть таблицю сумісності для точної моделі плати, потім звіряйте кожен приєднуваний компонент з її посібником. Ці перевірки стосуються конфігурацій вище; жодна з них не є перевіреним готовим кошиком покупок.
CPU
Підбирайте обчислювальну потужність під застосунок. Завдання, обмежене одним зайнятим потоком, виграє від ресурсів інакше, ніж ПЗ, здатне розподіляти роботу між ядрами. Файловий сервіс також залежить від дисків і мережі, тому дорогий CPU може не усунути початкового вузького місця.
Звірте сокет і чипсет, знайдіть точну модель CPU у списку підтримки плати й запишіть потрібну BIOS. Інструкція ASUS щодо сумісності CPU й пам’яті показує, де розміщені ці списки. Запитайте продавця, чи запускає встановлена BIOS обраний CPU. Також з’ясуйте, чи потрібні для інсталяції вбудована графіка або відеовихід контролера керування платою.
RAM
Місткості має вистачати для ОС і одночасних застосунків із запасом на зростання. Перевірте покоління DDR, максимальний обсяг, число слотів і порядок встановлення з посібника. Купівля всього початкового набору зі списку перевіреної пам’яті плати зменшує кількість поєднань для самостійної перевірки.
UDIMM означає небуферизовану пам’ять, RDIMM — регістрову. Це різні категорії модулів; сама наявність ECC не підтверджує сумісності. FAQ Supermicro щодо сумісності регістрової пам’яті прямо відхиляє регістрові DIMM для зазначеного сімейства X11SCA. Якщо потрібен ECC, підтвердьте підтримку CPU, платою й модулями. Збережіть можливість розширення без заміни всіх установлених модулів.
Сховище
Відокремлюйте пристрій ОС від бізнес-даних, якщо це спрощує ремонт і відновлення. SSD підходять навантаженням, чутливим до відгуку сховища; HDD надають місце для звичайних документів. В обох випадках перед вибором лише за місткістю перевірте призначення диска, гарантію, ресурс і доступність заміни.
RAID1 зберігає дзеркальні дані на парі дисків. Він витримує відмову одного учасника, але видалення, програма-вимагач і втрата майданчика потребують незалежної копії. Уточніть обсяг після форматування й залиште місце для зростання. Узгодьте SATA чи NVMe, розміри дисків, відсіки й кабелі. Перевірте, чи використання M.2 не вимикає потрібні дискам SATA-порти.
Материнська плата
Зафіксувавши сумісність CPU/BIOS і список перевіреної пам’яті QVL, перевірте підтримку Linux для вбудованої мережі й дискових контролерів, особливо на нових платформах.
Порахуйте потрібні роз’єми SATA, M.2, слоти PCIe та роз’єми вентиляторів. Вивчіть таблицю розподілу ліній: SSD чи плата розширення можуть зменшувати можливості іншого слота. Узгодьте формфактор і кріпильні отвори плати з корпусом. Віддалене керування корисне без монітора поруч, але потребує власного захищеного доступу й обслуговування прошивки.
Мережевий інтерфейс
Швидша мережева карта не прискорить повільний комутатор, клієнтське підключення чи сховище. Перед оплатою оновлення перевірте весь шлях. Візьміть гігабітне підключення офісного сценарію за основу, потім перевірте одночасне копіювання типових файлів.
Переконайтеся в наявності драйверів інтерфейсу для обраного Linux. Додатковій карті потрібні відповідний слот PCIe, вільне місце й підтримуване підключення. Під час купівлі врахуйте порти комутатора й кабелі: вони впливають на пропускну здатність разом із серверною NIC.
Блок живлення
Виберіть PSU, який відповідає корпусу та живить плату, CPU й диски через потрібні роз’єми. Врахуйте пускове навантаження та майбутнє розширення. Залиште належний запас за рекомендаціями виробників компонентів; велика потужність на етикетці сама по собі мало говорить про придатність.
Перевірте основне живлення плати й CPU, роз’єми дисків і довжину кабелів. Для модульного PSU використовуйте лише комплектні або прямо схвалені для точної моделі кабелі. Якщо корпус використовує фірмовий блок живлення, перевірте доступність заміни.
Охолодження
Узгодьте кулер із сокетом, межами потужності процесора й вільним місцем корпусу. Високі модулі пам’яті також можуть заважати. Перевірте наявність кріплення та дотримуйтеся інструкцій щодо термопасти й порядку затягування.
Забезпечте вільний рух повітря через диски й корпус. Додаткові вентилятори не виправлять перекритий потік чи шафу, яка утримує гаряче повітря. Перевірте допустимі навантаження роз’ємів і керування в посібнику. Після збірки виміряйте температури за типової роботи й відрегулюйте охолодження до введення в експлуатацію.
Корпус
Тиху баштову систему простіше розмістити в офісі, ніж обладнання для окремої серверної. Перевірте розмір плати, висоту кулера, відсіки й довжину карт. Порахуйте відсіки для завантажувального пристрою, початкових дисків і реалістичного плану заміни чи розширення.
Перевірте наявність кошиків, гвинтів і кабелів. Залиште місце для заміни диска без розбирання машини. Забезпечте доступ для чищення й сервісу, вільні отвори вентиляції та захист від випадкових ударів і від’єднання кабелів.
ДБЖ
ДБЖ дає серверу час коректно вимкнутися за втрати живлення. Вибирайте за очікуваним навантаженням, даними виробника про автономність і сумісним із Linux зв’язком для вимкнення. Потужність у ватах і час роботи батареї відповідають на різні питання.
Включіть комутатор, якщо вимоги передбачають локальний зв’язок під час знеструмлення. Сплануйте заміну батареї й перевірте коректне вимкнення за процедурою виробника. Не припускайте, що ДБЖ забезпечить роботу офісу під час тривалої аварії. Жодному з цих навантажень не потрібен GPU, якщо цього не вимагає конкретний застосунок.
Перед замовленням запишіть підтвердження біля вибраних деталей:
| Перевірте | Що записати до купівлі |
|---|---|
| CPU та RAM | Рядки списків підтримки, потрібна BIOS, категорія модулів і порядок слотів |
| Сховище й розширення | Доступні порти й відсіки та обмеження розподілу ліній |
| Механічна сумісність | Отвори плати, висота кулера й місце для карт |
| Живлення й відновлення | Потрібні роз’єми, підтримка вимкнення від ДБЖ і місце резервних копій |
Зберіть і перевірте обладнання
Неправильно встановлена стійка може торкатися звороту плати й пошкодити її. Працюйте за посібниками точних моделей із від’єднаним живленням; послідовність нижче загальна й не замінює їхніх схем.
- Перевірте компоненти й інструменти. До відкриття сокета підтвердьте підтримку CPU та BIOS. Збережіть пакування й серійні номери для гарантійних звернень.
- Підготуйте корпус. Залиште стійки тільки під отворами плати, зайві приберіть. Інструкція ASUS зі встановлення плати пояснює небезпеку зайвих стійок. За потреби встановіть окрему панель I/O.
- Встановіть CPU за мітками без зусилля. Дотримуйтеся процедури фіксатора сокета. Інструкція виробника зі встановлення CPU вимагає спочатку від’єднати мережевий шнур. Встановіть кулер із вказаною термопастою й способом кріплення; підключіть вентилятор CPU.
- Встановіть RAM у початкові слоти з посібника до правильної фіксації. Встановіть M.2, поки доступ зручний.
- Закріпіть плату й PSU. Встановіть завантажувальний диск і диски даних, приєднайте кабелі даних і живлення. За потреби додайте мережеву карту.
- Підключіть живлення плати й CPU, вентилятори корпусу та передню панель за посібником. Прокладіть кабелі подалі від вентиляторів. Перед подачею живлення перевірте вільні гвинти, незакріплені кабелі та не повністю вставлені роз’єми.
Під час першого запуску дочекайтеся завершення POST. У UEFI перевірте визначений CPU, загальну пам’ять, усі диски, вентилятори й температури. До встановлення ПЗ усуньте невиявлені деталі та ненормальні температури. Якщо потрібна прошивка, точно дотримуйтеся процедури виробника плати за стабільного живлення.
Запустіть доступну апаратну діагностику виробника й тест пам’яті для платформи. Після інсталяції скопіюйте типовий набір документів і перевірте звичайну одночасну роботу. Запишіть помилки, температури й час виконання як власні приймальні докази. Тест порожньої машини не підтверджує придатності для офісної роботи.
Встановіть Ubuntu й запустіть файловий ресурс
Офісна конфігурація надасть у LAN один ресурс business з автентифікацією. Використовуйте Ubuntu Server 24.04 LTS amd64 на підтримуваному обладнанні; у примітках до випуску зазначено супровід до травня 2029 року. Під час змін мережі тримайте доступною локальну консоль.
Встановіть ОС і змонтуйте сховище даних

Завантажте актуальний серверний інсталяційний образ 24.04 від Ubuntu та перед створенням USB виконайте перевірку підписаного образу за інструкцією Canonical. Перевіряються підпис контрольної суми й сама сума образу; не копіюйте хеш іншого завантаження.
Залиште незалежний резервний диск від’єднаним. Завантажте інсталятор і визначте внутрішні диски за моделлю, серійним номером і місткістю. У ручному налаштуванні розмістіть EFI-розділ і кореневу файлову систему ОС на завантажувальному SSD. З двох порожніх HDD створіть програмний MD RAID1, відформатуйте в ext4 і змонтуйте в /srv/business. Інструкція Canonical зі сховища описує створення й монтування MD-пристроїв.
Перевірте остаточну розмітку до підтвердження стирання. ОС має бути на завантажувальному SSD, а /srv/business — на дзеркалі; резервного диска не має бути видно. Під час інсталяції створіть особисту адміністративну учітку. Після перезавантаження перевірте розмітку:
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
findmnt --mountpoint /srv/business
cat /proc/mdstat
Переконайтеся, що /srv/business — змонтована ext4 на потрібному MD-пристрої, а обидва учасники дзеркала присутні й справні. Дочекайтеся початкової синхронізації до приймальних тестів. Зупиніться, якщо монтування відсутнє: інакше створення каталогів за цим шляхом розмістить бізнес-файли на завантажувальній файловій системі.
Обмежте адміністрування й мережевий доступ
Зарезервуйте адресу сервера в DHCP роутера. Приклади використовують сервер 192.168.10.10, офісну підмережу 192.168.10.0/24 і клієнт адміністратора 192.168.10.20. Замініть своїми значеннями. Перевірте LAN роутера й адресу та маску клієнта; /24 описує діапазон цього прикладу, а не кожну офісну мережу. Локальним файлам не потрібні публічна IP-адреса чи придбаний DNS.
Застосуйте оновлення й встановіть пакети:
sudo apt update
sudo apt upgrade
sudo apt install samba smbclient restic ufw
Для віддаленого адміністрування встановіть openssh-server, налаштуйте SSH-ключ адміністратора й перевірте його в другій сесії. Першу не закривайте. Інструкція Canonical з OpenSSH містить налаштування ключів і перевірки конфігурації. Після кожної зміни SSH запускайте sudo sshd -t та зберігайте доступ із паролем, поки вхід із новим ключем не працює.
Для цього SSH-доступу перед увімкненням UFW замініть адресу й фактичний порт SSH у першому правилі дозволу. За адміністрування лише з консолі пропустіть правило. Інструкція Canonical з брандмауера описує обмеження за джерелом:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 192.168.10.20 to any port 22
sudo ufw allow proto tcp from 192.168.10.0/24 to any port 445
sudo ufw enable
sudo ufw status verbose
Повторно перевірте зв’язок адміністратора. Порт 445 забезпечує цей файловий доступ SMB; не перенаправляйте його через інтернет-роутер. Гостьовий Wi-Fi залиште в окремій мережі без доступу до офісного сервісу. Правило підмережі не розрізняє працівників і гостей у тій самій підмережі.
Створіть файловий ресурс з автентифікацією
Дайте кожному працівнику Linux-обліковий запис і окремі дані Samba. Інструкція Ubuntu з керування доступом Samba вимагає існування Linux-учітки до реєстрації. Для нового суто файлового користувача alex виконайте:
sudo addgroup officefiles
sudo adduser --disabled-password --shell /usr/sbin/nologin alex
sudo adduser alex officefiles
sudo smbpasswd -a alex
sudo mkdir -p /srv/business/team
sudo chown root:officefiles /srv/business/team
sudo chmod 2770 /srv/business/team
sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.before-business
sudoedit /etc/samba/smb.conf
Введіть пароль Samba для Alex за запитом. Вимкнений Linux-пароль і оболонка nologin відокремлюють цю учітку від адміністративних входів; не додавайте її до sudo. Повторіть створення користувача, групу й реєстрацію Samba для кожного працівника, створивши officefiles лише раз.
Режим 2770 дає доступ власнику й групі, забороняє іншим і встановлює setgid, щоб нові елементи успадковували групу каталогу. І правила Samba, і права файлової системи Linux мають дозволяти операцію. Збережіть глобальну конфігурацію й додайте цей один ресурс:
[business]
path = /srv/business/team
browseable = yes
guest ok = no
read only = no
valid users = @officefiles
force group = officefiles
create mask = 0660
force create mode = 0660
directory mask = 2770
force directory mode = 2770
Запис @officefiles обмежує доступ учасниками групи; force group утримує операції ресурсу в цій групі. Маски обмежують права нових файлів і каталогів, як описує довідник конфігурації Samba Ubuntu. Перевірте й запустіть сервіс:
sudo testparm -s
sudo systemctl restart smbd
sudo systemctl status smbd --no-pager
Усуньте помилки конфігурації до перезапуску. Перевірка синтаксису підтверджує здатність Samba завантажити конфігурацію, а наступний клієнтський тест — придатність сервісу до роботи.
Перевірте з клієнта
На другому Windows-комп’ютері в дозволеній LAN відкрийте \\192.168.10.10\business у Провіднику. Увійдіть як alex з паролем Samba. Створіть acceptance.txt, напишіть коротке речення, закрийте й знову відкрийте. Додайте іншого працівника й підтвердьте, що його облікові дані дозволяють редагувати спільний тестовий файл.
З Linux-клієнта з установленим smbclient можна підключитися так:
smbclient //192.168.10.10/business -U alex
Введіть пароль за запитом. Перевірте неправильні дані й гостьову спробу без автентифікації: жодна не має дозволяти читання чи створення файлів. У Windows від’єднайте чинний ресурс і очистьте збережені дані до перевірки забороненого користувача, інакше може залишитися успішна сесія.
У разі тайм-ауту перевірте адресу сервера й LAN-шлях, правило джерела та порту UFW і стан smbd. Якщо вхід або запис не працює, перевірте реєстрацію Samba, id alex і ls -ld /srv/business/team. Підтвердьте групу й власника каталогу. Не вмикайте гостьовий доступ і запис для всіх як спосіб усунення помилки.
Сплануйте витрати на власність і оренду
Припустімо, купуються сервер за 1 500 доларів, ДБЖ за 200 і обладнання локальних копій за 300. Це окремі вхідні дані моделі, а не розбивка попереднього бюджету. Приймемо середню потужність від розетки 100 Вт і електроенергію по 0,15 долара за кВт·год:
100 / 1000 × 24 × 365 × 3 × 0.15 = $394.20
Ані потужність, ані тариф не виміряні. Для обох самостійно керованих варіантів закладіть 2 години адміністрування щомісяця по 25 доларів за годину й 10 доларів щомісяця на незалежну копію поза майданчиком:
| Гіпотетичні витрати за 36 місяців | Власність | Оренда |
|---|---|---|
| Обладнання, ДБЖ і локальні резервні копії | $2,000.00 | Передбачаються обладнання й майданчик провайдера |
| Орендна плата | – | $1,080.00 |
| Електроенергія локального сервера | $394.20 | Включено до прийнятої орендної плати |
| Незалежні копії поза майданчиком | $360.00 | $360.00 |
| Проміжний грошовий підсумок | $2,754.20 | $1,440.00 |
| Розрахункове адміністрування | $1,800.00 | $1,800.00 |
| Загалом з урахуванням праці | $4,554.20 | $3,240.00 |
Орендний варіант не передбачає окремого локального пристрою копіювання; незалежні копії поза майданчиком мають власний рядок для обох варіантів.
Створіть копії, відновіть дані й передайте сервіс
Відновіть acceptance.txt і конфігурацію Samba до введення бізнес-файлів у роботу. Використовуйте окремо змонтований зовнішній диск із наявною файловою системою й достатнім місцем, потім зберігайте другу незалежно захищену копію поза майданчиком. Команди нижче не готують і не стирають диски.
Змонтуйте резервний диск у /media/business-backup. Через findmnt і lsblk підтвердьте, що це потрібний зовнішній пристрій, а не каталог у внутрішньому сховищі сервера. Відкрийте привілейовану оболонку, щоб restic міг читати ресурс і конфігурацію:
sudo -i
findmnt --mountpoint /media/business-backup
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
Підтвердивши пристрій, ініціалізуйте репозиторій і зробіть копію. Ланцюжок && зупиняється після помилки, зокрема відсутнього монтування:
findmnt --mountpoint /media/business-backup &&
restic -r /media/business-backup/restic init &&
restic -r /media/business-backup/restic backup /srv/business /etc/samba &&
restic -r /media/business-backup/restic snapshots &&
restic -r /media/business-backup/restic check
Новий репозиторій ініціалізують лише раз. Restic запитує пароль репозиторію; зберігайте його окремо в корпоративному сховищі облікових даних. Короткий посібник Restic описує ці операції. Якщо перевірка монтування не пройшла, зупиніться, щоб не створити репозиторій на диску хоста.
Не змінюйте тестового документа під час перевірки. У тій самій root-оболонці відновіть лише цей файл і конфігурацію Samba в новий порожній каталог /srv/restore-check. Переконайтеся, що для вибраних елементів достатньо місця:
mkdir /srv/restore-check &&
restic -r /media/business-backup/restic restore latest --target /srv/restore-check --include /srv/business/team/acceptance.txt --include /etc/samba &&
cmp /srv/business/team/acceptance.txt /srv/restore-check/srv/business/team/acceptance.txt &&
cat /srv/restore-check/srv/business/team/acceptance.txt &&
testparm -s /srv/restore-check/etc/samba/smb.conf
exit
Інструкція Restic з відновлення описує цільові шляхи й перезапис. cmp не має знаходити відмінностей, відновлений текст має читатися, а testparm — приймати відновлену конфігурацію. Це перевіряє відновлення файлів і конфігурації, а не повне аварійне відновлення.
Призначте нічні копії після закриття файлів, зберігання семи щоденних і чотирьох щотижневих знімків, щотижневу перевірку репозиторію та щомісячну вправу відновлення. Нічні копії допускають втрату приблизно денних змін; виміряйте час відновлення. Інструкція Restic зі зберігання знімків дозволяє спочатку переглянути видалення через forget --keep-daily 7 --keep-weekly 4 --dry-run. Forget видаляє посилання на знімки, prune — непотрібні збережені дані. Перегляньте пробний результат до видалення. Наявність знімків не доводить виконання пропущених завдань.
Для автоматизації захистіть облікові дані файлом пароля лише для root або сховищем секретів, перевіряйте монтування диска в завданні й сповіщайте власника про збій. Ротація потребує приєднання правильного диска перед завданням, від’єднання після й незалежного підтримання копії поза майданчиком.
Запишіть ID користувачів і груп та порядок додавання працівників. На замінному хості потрібні заново створені Linux/Samba-ідентичності, збережені або виправлені власники, відновлені файли й конфігурація та нова клієнтська перевірка. Копія лише /etc/samba не відновлює окремого стану облікових даних Samba.
Передайте дані про власника й заступника, вікно оновлень і перезапуску, процедуру вимкнення від ДБЖ і перевірки вільного місця, дзеркала, журналів та результатів копіювання. До прийняття сервісу зафіксуйте успішне відновлення файлу та витрачений час.
Обговорення
Коментарі
Увійдіть, щоб долучитися до обговорення.