Мебельное производство: 3 ТБ чертежей и раскроя — свой файловый сервер вместо флешек

MAATRIX

На мебельном производстве от пяти до двадцати человек чертежи и карты раскроя чаще всего живут в двух местах: в голове конструктора и на флешке, которая ходит по цеху из рук в руки. Пока заказов немного, схема работает — почти всегда. Но стоит вырасти до пары параллельных заказов в работе и сменного графика в цехе раскроя, как начинают путаться версии, теряться флешки с актуальным файлом и накапливаться гигабайты дублей на компьютере у каждого. Дальше — как заменить это одним файловым сервером, доступным всем этапам производства по сети, без абонентской платы за каждое рабочее место.

Почему флешка работает, пока производство маленькое

Типичный путь файла на небольшом мебельном производстве такой: конструктор рисует изделие и раскрой в своей CAD-программе, экспортирует чертежи и карту раскроя (часто в DXF, PDF и таблицу с спецификацией), копирует всё на флешку и несёт её в цех раскроя. Там файл открывают на компьютере у распиловочного станка или форматно-раскроечного центра, режут материал. Готовые детали и остаток спецификации передают дальше — на сборку, где нужна уже другая часть того же комплекта документов: сборочный чертёж, схема фурнитуры, ведомость деталей.

Пока в работе один заказ и один комплект файлов, физическая передача флешки — это просто лишний шаг, но не источник ошибок. Проблемы начинаются, когда:

• заказов в работе несколько, и конструктор правит чертёж по заказу №2, пока цех ещё режет по заказу №1 с той же флешки;
• в цехе раскроя посменная работа, и вторая смена получает не ту флешку, что была утром;
• у сборщика на планшете лежит копия недельной давности, потому что «удобнее было один раз скинуть и не бегать каждый день».

Ни один из этих сценариев не редкость — это нормальный побочный эффект роста производства мимо той стадии, когда один человек держит в голове весь процесс.

Что на самом деле теряется на флешках

Дело не только в потерянной флешке как таковой (хотя и это случается — потерять накопитель с единственной актуальной версией раскроя на кухонный гарнитур на 300 тысяч рублей означает в лучшем случае день простоя цеха, в худшем — раскрой по памяти конструктора, что означает риск пересчёта или лишнего материала). Дороже обходятся менее заметные вещи:

• Рассинхронизация версий. Конструктор внёс правку по требованию клиента (изменили размер модуля, поменяли петли), но в цехе уже открыт файл с флешки, скопированной час назад до правки. Деталь режут по старому размеру.
• Отсутствие истории. Когда клиент через месяц спрашивает «а почему у меня фасад на 3 мм уже, чем в замере», ответить нечем — предыдущая версия чертежа никуда не сохранялась, флешку просто перезаписали.
• Разные копии на разных машинах. У конструктора один вариант, в цехе раскроя — другой, у мастера на сборке — третий. Каждый уверен, что его копия последняя.
• Утечка через USB. Флешки — это ещё и стандартный вектор для вирусов-шифровальщиков, которые гуляют между цеховыми компьютерами с устаревшим софтом именно через сменные накопители.

Всё это не про катастрофу раз в год, а про постоянные мелкие потери времени и материала, которые никто не считает отдельной строкой, но которые складываются в заметную часть накладных расходов небольшого производства.

Как устроен файловый сервер для мебельного цеха

Идея простая: один центральный сервер с общим хранилищем, к которому по сети подключены компьютер конструктора, компьютер (или планшет) у станка в цехе раскроя и рабочее место сборщика. Файл лежит в одном месте, все работают с одной и той же актуальной версией, физическая передача накопителей исчезает как класс.

Технически это можно собрать двумя способами:

Сетевая папка (SMB/Samba). Классический вариант, который не требует от сотрудников ничего нового — папка на сервере подключается как обычный сетевой диск, работает из любой CAD-программы и раскроечного софта напрямую, без промежуточной синхронизации. Минимальный конфиг общей папки в Samba выглядит так:

[chertezhi]
   path = /srv/mebel/chertezhi
   valid users = @konstruktory, @cex_raskroya, @sborka
   read only = no
   create mask = 0664
   directory mask = 0775

Веб-хранилище (Nextcloud или Seafile). Даёт то же самое сетевое хранилище, но плюс историю версий файлов из коробки, доступ через браузер без VPN и синхронизацию на ноутбук, если конструктор иногда работает из дома. Дороже по ресурсам сервера и чуть менее прозрачно интегрируется с раскроечным ПО, которое ждёт обычный путь к файлу, а не облачную папку. Разница между этими двумя подходами разобрана в сравнении Nextcloud и Seafile — для чисто файлового хранилища без сложных совместных правок часто хватает и простого SMB.

Многие производства в итоге комбинируют оба варианта: Samba-папка как основное хранилище, к которому у станков и в цехе привычный сетевой диск, и веб-доступ поверх неё для конструктора и руководителя, которым иногда нужно посмотреть чертёж не с рабочего места.

Структуру папок стоит продумать заранее, а не «как получится» — переносить 3 ТБ файлов с плоской структурой на нормальную иерархию через полгода работы гораздо больнее, чем сразу договориться о шаблоне:

/srv/mebel/
├── 01-zakazy/
│   ├── 2026-08-ivanov-kuhnya/
│   │   ├── chertezhi/
│   │   ├── raskroj/
│   │   └── spetsifikaciya.pdf
│   └── 2026-08-petrova-shkaf-kupe/
├── 02-shablony/
├── 03-arhiv-zakryto/
└── 04-materialy-i-furnitura/

Отдельная папка 03-arhiv-zakryto для завершённых заказов — не формальность: если держать все заказы, включая закрытые пять лет назад, в одной куче с активными, поиск актуального файла в цехе раскроя превращается в квест.

Права доступа: кто видит раскрой, а кто — только сборку

Соблазн дать всем полный доступ ко всей папке — самый частый способ получить проблему через полгода. У конструктора должно быть право менять чертежи и карты раскроя. У цеха раскроя — право читать чертежи и карты раскроя, но не обязательно право их удалять или перезаписывать. У сборщика вообще не должно быть доступа к внутренней конструкторской документации, если это не нужно по работе — только к сборочным схемам готового заказа.

На практике это делается через группы пользователей на сервере и valid users/write list в конфиге Samba (или через группы и ACL, если хранилище на Linux-файловой системе):

groupadd konstruktory
groupadd cex_raskroya
groupadd sborka

usermod -aG konstruktory ivan_konstruktor
usermod -aG cex_raskroya oleg_raskroj

chgrp -R konstruktory /srv/mebel/01-zakazy
chmod -R 2770 /srv/mebel/01-zakazy

Флаг 2770 со «липким» битом группы (2) гарантирует, что все новые файлы и подпапки, которые создаст конструктор внутри 01-zakazy, унаследуют ту же группу — иначе через месяц половина файлов окажется недоступна для чтения остальным, и разбираться с этим руками на живом производстве неприятно. Про то, как выглядит эта проблема на практике, когда права выставили один раз и забыли, есть отдельный разбор: скопировали два терабайта и потеряли права доступа — стоит прочитать перед тем, как заливать архив на новый сервер целиком одной командой.

Отдельно стоит закрыть на чтение-запись для всех, кроме ответственного, папку с шаблонами (02-shablony) — это болванки чертежей и стандартные карты раскроя, по которым строится большая часть новых заказов, и случайная правка шаблона распространяется на все следующие изделия незаметно.

Версии чертежей — чтобы цех не резал по старому файлу

Главная причина брака из-за рассинхронизации версий — не отсутствие сервера, а отсутствие договорённости о том, что считается «актуальной» версией. Файловый сервер сам по себе эту проблему не решает, если конструктор по привычке продолжает плодить копии kuhnya_final.dwg, kuhnya_final2.dwg, kuhnya_final_ISPRAVLENO.dwg.

Здесь работают два подхода, и лучше выбрать один и держаться его:

• Версии в имени файла по договорённости. Например, zakaz-ivanov_rev03_2026-08-20.dxf, и в папке заказа всегда есть файл TEKUSHAYA-VERSIYA.dxf (или symlink на неё), на который смотрит цех раскроя, — не нужно объяснять оператору станка, что «rev03 больше, чем rev02».
• Встроенная история версий хранилища. Nextcloud и Seafile хранят предыдущие версии файла автоматически при каждом сохранении — можно откатиться и посмотреть, что менялось, без ручного нейминга. Правило то же: у файла в рабочей папке всегда одно имя, история — внутри системы, а не в виде десятка копий рядом.

Про то, как эта задача решается для похожей роли — человека, который правит один и тот же файл много раз подряд и должен предсказуемо публиковать актуальную версию, — есть отдельная статья про версии чертежей конструктора на своём сервере, где разобрана механика версионирования подробнее.

Что бы вы ни выбрали, донесите правило до цеха одной фразой на табличке у станка: «режем только по файлу из папки текущего заказа, не по локальным копиям на рабочем столе». Большая часть инцидентов с раскроем по старому чертежу происходит не из-за плохого софта, а из-за локальной копии, которую кто-то сохранил себе на рабочий стол компьютера у станка «на всякий случай» ещё в марте.

Резервное копирование и что делать, если сервер откажет

3 ТБ чертежей и раскроя, накопленных за годы работы, — это актив, который стоит защищать так же, как станочный парк. Если сервер с единственной копией этих файлов выйдет из строя, а бэкапа нет, производство останавливается не физически (станки целы), а информационно — резать и собирать банально не по чему.

Минимальная схема бэкапа, которая закрывает большинство рисков:

# ежедневный инкрементальный бэкап на отдельный диск/сервер
restic backup /srv/mebel --repo /mnt/backup-disk/mebel-repo

# хранить снапшоты за последние 7 дней, 4 недели, 6 месяцев
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Важное правило — копия должна лежать не на том же физическом диске, что рабочие файлы, а лучше вообще на другом сервере или в другом дата-центре. Если основной файловый сервер стоит в России, вторую копию разумно держать на отдельном арендованном сервере в другой локации — это защищает не только от сбоя диска, но и от локальных проблем с электричеством или сетью в конкретном ЦОД. Для самого файлового хранилища тоже стоит заранее продумать локацию и объём диска — например, выделенный сервер в Великобритании для файлового хранилища на терабайты закрывает задачу и как основное хранилище, и как точка для второй копии бэкапа, если основной сервер работает в другой стране.

Не обязательно строить сложную catastrophe recovery инфраструктуру для производства на десять человек — но простое правило «бэкап хотя бы раз в сутки, копия хотя бы в одном месте отдельно от рабочего сервера» снимает большую часть риска ценой пары часов настройки один раз.

Частые вопросы