SMM-специалист хранит контент-планы и 200 ГБ креативов клиентов

MAATRIX

Если вы ведёте больше двух-трёх клиентов одновременно, вы уже знаете это чувство: открываешь Google Диск, а там красная полоска «Хранилище почти заполнено», хотя вы вроде бы всё чистили месяц назад. Фото и видео для постов, сторис, рилсов копятся быстрее, чем успеваешь их разбирать, а бесплатный тариф рассчитан явно не на агентство из пяти аккаунтов. Ниже — как перестать бороться с лимитами облака и организовать хранилище контента клиентов на собственном сервере: с понятной структурой, доступом для команды и без ежемесячного «а не удалить ли старые сторис».

Почему бесплатное облако не тянет работу SMM-специалиста

Проблема не в том, что облако плохое — оно просто не рассчитано на профессиональный объём медиа. Бесплатный тариф Google Диска даёт около 15 ГБ на аккаунт, Dropbox — и того меньше. Если у вас 200 ГБ креативов клиентов (условная, но реалистичная цифра для агентства с полудюжиной проектов — у кого-то будет 80 ГБ, у кого-то 400), вы либо платите за расширенный тариф на своём личном аккаунте, либо заводите отдельные аккаунты под каждого клиента и путаетесь, куда что залили.

Тут накладываются ещё две вещи, характерные именно для SMM:

• Смешение форматов. В одной папке живут исходники фото в RAW или HEIC от фотографа, готовые видео от монтажёра, PSD-макеты от дизайнера, экспортированные сторис и сам контент-план в Google Таблице или Notion. Найти нужный файл через месяц — квест.
• Разный доступ у разных людей. Клиенту нужно видеть готовые посты и утверждать их, дизайнеру — кидать исходники, вам — держать архив всего цикла. В личном облаке это либо один расшаренный на всех линк без разбора, либо десяток отдельных папок с разными правами, которые быстро расползаются.

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

Как разложить контент-планы и креативы по клиентам: структура каталогов

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

/data/clients/
├── client-a/
│   ├── content-plan/          # таблицы, тексты постов, календарь публикаций
│   ├── creatives/
│   │   ├── raw/                # исходники от фотографа/видеографа, не трогаем
│   │   ├── in-progress/        # монтаж, ретушь, дизайн в работе
│   │   └── ready/              # готово к публикации, отсортировано по датам
│   ├── published/              # архив того, что уже вышло — для отчётов
│   └── brand-assets/           # логотипы, шрифты, брендбук клиента
├── client-b/
│   └── ...
└── _templates/                 # шаблон структуры для нового клиента

Разделение raw / in-progress / ready избавляет от главной боли — когда непонятно, финальная это версия видео или ещё черновик. А отдельная папка published даёт готовый архив для отчётов клиенту: не нужно рыться в ленте соцсети, чтобы вспомнить, что публиковали в марте.

Если сейчас всё лежит вперемешку в облаке, перенос — хороший повод навести порядок один раз, а не переносить бардак один в один. Похожая логика разделения на «исходники / в работе / готово» встречается у фотографов и видеографов — принцип один и тот же независимо от типа контента.

Разворачиваем Nextcloud на сервере: пошагово

Голая файловая структура на диске — это уже рабочий вариант (доступ по SFTP или через смонтированную сетевую папку), но для команды из нескольких человек и клиентов, которым нужно смотреть контент через браузер, удобнее веб-интерфейс. Nextcloud закрывает это одним пакетом: файлы, предпросмотр фото и видео, доступ по ссылке, права на папки.

Минимальная установка на Ubuntu 24.04 (сервер с 2 ядрами и 4 ГБ RAM уже потянет команду до 5-7 человек):

apt update && apt install -y apache2 mariadb-server \
  php php-gd php-mysql php-curl php-mbstring php-intl \
  php-imagick php-xml php-zip php-bz2 php-gmp php-bcmath

# создаём базу
mysql -u root -e "
CREATE DATABASE nextcloud CHARACTER SET utf8mb4;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;"

cd /var/www
curl -O https://download.nextcloud.com/server/releases/latest.zip
unzip latest.zip
chown -R www-data:www-data nextcloud

После установки через веб-мастер (или occ maintenance:install из консоли) сразу создайте групповую структуру, а не отдельного пользователя на каждого клиента вручную:

sudo -u www-data php occ group:add clients
sudo -u www-data php occ group:add team

sudo -u www-data php occ user:add --group=team designer1
sudo -u www-data php occ user:add --group=clients client-a

Папку клиента монтируете как «Внешнее хранилище» (External storage) на существующий раздел диска /data/clients/client-a, либо просто создаёте её штатно в Nextcloud — если данных пока немного, второй вариант проще для старта, а перенос на смонтированный раздел можно сделать позже без потери файлов.

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

Права доступа и шаринг с клиентами и фрилансерами в команде

Смысл своего сервера — не просто «то же облако, но своё», а нормальная модель доступа. В Nextcloud это делается через группы и точечный шаринг папок:

• Клиенту — доступ только к своей папке published и, при желании, к ready для утверждения перед публикацией. Права «только чтение» плюс возможность комментировать файл — этого обычно достаточно, не давайте прав на удаление и перемещение.
• Фрилансеру-монтажёру или дизайнеру — доступ к raw и in-progress конкретного клиента, без доступа к остальным клиентам вообще. В Nextcloud это управляется через occ files:transfer-ownership или через групповые папки (Group folders — есть в приложении из каталога), где для каждой папки клиента заводится своя группа.
• Себе — полный доступ ко всему, плюс отдельный аккаунт-администратор без ежедневного использования (для операций с базой и сервером, а не для обычной работы с файлами — на случай, если рабочий аккаунт скомпрометируют).

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

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

Синхронизация с телефоном, ноутбуком и приложением для съёмки

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

• Nextcloud-приложение на телефоне — включаете автозагрузку камеры в конкретную папку (raw/mobile), дальше файлы попадают на сервер сами по Wi-Fi без вашего участия, как это делает Google Photos, только в вашу собственную папку клиента.
• Настольный клиент Nextcloud на ноутбуке синхронизирует выбранные папки клиентов двусторонне — правите файл локально в Lightroom или Premiere, он подтягивается на сервер автоматически.
• rclone — если часть архива всё ещё лежит в старом облаке и нужно перенести без ручного скачивания-загрузки:

rclone config              # добавляете Google Drive как источник
rclone sync gdrive:client-a-2026 /data/clients/client-a/published \
  --progress --transfers 8

Перенос 200 ГБ через rclone займёт часы, а не дни ручного перетаскивания, и его можно запустить на ночь, не сидя перед экраном. Учитывайте, что реальная скорость зависит от вашего интернет-канала и лимитов API облачного провайдера — точных цифр по времени тут дать нельзя, у каждого будет по-своему.

Резервное копирование архива клиентов

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

Рабочий минимум — ежедневный инкрементальный бэкап через borgbackup на отдельный диск или в другую локацию:

apt install borgbackup

# инициализация репозитория (один раз)
borg init --encryption=repokey /backup/clients-repo

# бэкап всех клиентов, запускается по cron
borg create --stats --compression zstd \
  /backup/clients-repo::clients-{now:%Y-%m-%d} \
  /data/clients

# хранить последние 14 ежедневных, 8 недельных, 6 месячных копий
borg prune /backup/clients-repo \
  --keep-daily=14 --keep-weekly=8 --keep-monthly=6

Добавьте это в cron на ночное время и обязательно раз в месяц проверяйте, что бэкап реально восстанавливается — borg extract на тестовую папку, а не «наверное, всё нормально». Подробный разбор установки и частых ошибок с BorgBackup есть в статье BorgBackup на Ubuntu 24.04, если хотите развернуть по шагам.

Отдельно стоит помнить про миф, что RAID на сервере — это уже резервная копия. Это не так: RAID защищает от отказа одного физического диска, но не от случайного удаления файла или шифровальщика. Бэкап на отдельном носителе или в другой локации остаётся обязательным вне зависимости от того, какой у вас диск в сервере.

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