Копирайтер потерял архив текстов вместе с аккаунтом: своё хранилище

MAATRIX

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

Почему архив в чужом аккаунте — это бомба замедленного действия

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

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

Отдельная проблема — то, что copywriting-архив специфичен: это не бухгалтерские отчёты, которые можно восстановить из внешних источников. Черновик с правками заказчика, финальная версия текста, которая продавала лучше остальных вариантов A/B-теста, переписка в комментариях к документу — всё это существует в одном экземпляре. Потеряв аккаунт, вы теряете не файлы, а доказательства своей работы: то, чем открывается разговор с новым клиентом на словах «покажите примеры».

Что конкретно теряет копирайтер вместе с доступом

Стоит разложить архив на составляющие, чтобы понять масштаб потери:

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

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

Как устроено собственное хранилище: сервер вместо аккаунта

Идея простая и не новая: вместо того чтобы держать архив внутри чужого продукта, вы держите его в файловой системе сервера, которым управляете сами — через SSH-ключ и root-доступ, а не через логин и пароль от чужого сервиса. Дальше поверх этой файловой системы можно поставить удобную оболочку, но принципиально важно вот что: даже если у оболочки завтра не станет (разработчик закроет проект, изменится лицензия), сами файлы остаются на диске в открытом формате — markdown, docx, txt — и их можно скопировать, открыть, продолжить работать.

Практически для копирайтера подходят два разных по духу инструмента, и выбор зависит от того, как вы привыкли работать:

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

Ничто не мешает использовать оба сразу: длинные готовые материалы — файлами в Nextcloud, рабочие заметки и заготовки — в Trilium. Оба варианта разворачиваются на одном и том же сервере.

Установка: разворачиваем хранилище за один вечер

Для файлового архива самый практичный путь — Nextcloud в Docker. На чистом сервере с Ubuntu ставится Docker и Docker Compose, дальше — минимальный docker-compose.yml:

version: "3"
services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "смените_на_свой"
      MYSQL_PASSWORD: "смените_на_свой"
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
    volumes:
      - db_data:/var/lib/mysql

  app:
    image: nextcloud:latest
    restart: unless-stopped
    ports:
      - "8080:80"
    depends_on:
      - db
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: "смените_на_свой"
    volumes:
      - nextcloud_data:/var/www/html

volumes:
  db_data:
  nextcloud_data:

docker compose up -d

После первого запуска на порту 8080 откроется мастер настройки — создаётся администратор, и дальше сервис работает как обычный облачный диск, только физически расположенный на вашей машине. Дальше стоит сразу поставить обратный прокси (nginx или Caddy) с бесплатным TLS-сертификатом, чтобы работать через https://ваш-домен, а не через голый IP и порт — это удобнее и безопаснее для доступа с телефона в дороге.

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

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

Организация архива и поиск по годам работы

Голое хранилище без структуры превращается в такую же кашу, как и папка «Загрузки» на компьютере, поэтому имеет смысл сразу договориться с собой о структуре. Рабочий вариант, который легко расширять:

/archive
  /2023
    /client-name-project
      brief.md
      draft-v1.md
      final.md
      notes.md
  /2024
    ...
  /templates
    landing-structure.md
    email-sequence.md
  /portfolio
    best-cases.md

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

Важный честный момент: встроенный поиск в Nextcloud по умолчанию ищет по названиям файлов, а не по содержимому текста — полнотекстовый поиск требует отдельного приложения с поисковым движком (Elasticsearch) и лишней нагрузки на сервер, которая для архива на несколько тысяч документов обычно не оправдана. Практичнее держать тексты в markdown или txt и искать по содержимому напрямую через SSH:

grep -rli "ключевая фраза" /var/www/html/data/username/files/archive/

или, если на сервере есть ripgrep (apt install ripgrep), заметно быстрее и с подсветкой совпадений:

rg -i "ключевая фраза" ~/archive/

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

Резервные копии: чтобы не повторить тот же сценарий на своей инфраструктуре

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

Практичная связка — restic с шифрованием, запущенный по расписанию через cron, который складывает снапшоты архива во второе хранилище (второй сервер, объектное хранилище S3-совместимого типа или даже внешний диск):

restic -r sftp:user@backup-host:/backups/archive init
restic -r sftp:user@backup-host:/backups/archive backup /var/www/html/data/username/files/archive

В cron это оформляется одной строкой на ежедневный запуск:

0 3 * * * restic -r sftp:user@backup-host:/backups/archive backup /var/www/html/data/username/files/archive >> /var/log/restic-archive.log 2>&1

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

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

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