Писатель боится потерять рукопись: версии черновиков на своём сервере

MAATRIX

Ночью в голове крутится не сюжет, а мысль: а если ноутбук сейчас умрёт? Рукопись, над которой вы работали месяцами, а то и годами, лежит в одном файле на одном диске — и весь этот труд держится на честном слове старого SSD. Страх потерять роман знаком любому автору не понаслышке, а хаос из файлов «глава3_новая», «глава3_финал», «глава3_финал_ИСПРАВЛЕНО» только усиливает тревогу: непонятно, где актуальная версия, а где та, что вы отменили ещё в марте. Свой сервер с автоматическим бэкапом и версионированием черновиков решает обе проблемы разом — рукопись защищена от потери, а история правок хранится структурированно, а не в названиях файлов.

Почему папка на ноутбуке — это не защита

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

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

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

Хаос имён файлов — это симптом, а не решение

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

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

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

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

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

1. Версионирование — каждое сохранение текста фиксируется как отдельный «коммит» с описанием, что изменилось. Можно посмотреть всю историю правок, сравнить любые две версии построчно, откатиться к состоянию на любую дату.
2. Резервное копирование — весь сервер целиком (включая git-репозиторий со всей историей) регулярно копируется в отдельное зашифрованное хранилище, недоступное шифровальщику и не зависящее от диска ноутбука.

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

Работает это с любым текстовым редактором, который сохраняет обычные текстовые файлы или markdown — .txt, .md, .rtf в текстовом виде тоже отслеживается, хотя для форматированных .docx система контроля версий покажет только «файл изменился», а не построчную разницу, потому что docx — это архив с разметкой, а не чистый текст. Если вы пишете в редакторе, который позволяет экспортировать или сохранять текст сцен в markdown или .txt — вы получите максимум пользы от построчных сравнений. Если работаете только в .docx — версии всё равно будут сохраняться и откатываться, просто без построчного diff внутри документа.

Настройка git-репозитория для рукописи

Git — система контроля версий, которую используют программисты, но правила у неё простые и подходят для текста романа не хуже, чем для кода. На сервере создаём «голый» репозиторий, который служит центральным хранилищем:

# на сервере
mkdir -p ~/repos/roman.git
cd ~/repos/roman.git
git init --bare

На своём компьютере клонируем его и кладём туда рукопись — например, по одной главе в отдельном markdown-файле, так удобнее видеть, что именно поменялось:

git clone ssh://user@ваш-сервер/~/repos/roman.git
cd roman
mkdir glavy
mv ~/Documents/glava1.md glavy/
mv ~/Documents/glava2.md glavy/
git add .
git commit -m "Черновик глав 1-2"
git push origin main

Дальше вся работа сводится к одной привычке: после сессии письма — сохранить и зафиксировать изменения с коротким комментарием, что вы сделали:

git add glavy/glava3.md
git commit -m "Глава 3: переписан диалог в конце сцены"
git push

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

git log --oneline glavy/glava3.md

А сравнить текущую версию с любой из прошлых — командой git diff, которая построчно покажет, что добавлено и что убрано:

git diff HEAD~5 -- glavy/glava3.md

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

git tag chernovik-1-zavershyon
git push --tags

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

Автоматический бэкап поверх версий

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

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

# инициализация зашифрованного хранилища бэкапов
restic -r /mnt/backup-disk/roman-backup init

# сам бэкап папки с репозиторием
restic -r /mnt/backup-disk/roman-backup backup ~/repos/roman.git

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

# crontab -e
0 3 * * * restic -r /mnt/backup-disk/roman-backup backup /home/user/repos/ --tag daily

Восстановление в случае проблемы — тоже одна команда, снимок можно выбрать по дате:

restic -r /mnt/backup-disk/roman-backup restore latest --target /home/user/vosstanovlenie

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

Синхронизация черновика между устройствами

Пишете дома на десктопе, в дороге — на ноутбуке, а иногда правите абзац с планшета в метро? Здесь можно пойти двумя путями. Первый — тот же git: перед началом работы делать git pull, после — git push, тогда актуальная версия всегда явно «получена» и «отправлена», без риска редактировать устаревший текст.

Второй путь — если вам не хочется каждый раз вспоминать команды git, папку с рукописью можно синхронизировать между устройствами и сервером в реальном времени через Syncthing: изменили абзац на ноутбуке — через несколько секунд то же самое видно на сервере и на десктопе, без ручных команд. При этом сам сервер уже отдельно бэкапится и версионируется через git — Syncthing синхронизирует «последнее состояние», а git и restic отвечают за историю и восстановление. Как поднять Syncthing на сервере — в статье про установку и настройку Syncthing на VPS.

Комбинация «Syncthing для мгновенной синхронизации плюс git для истории плюс restic для бэкапа сервера» закрывает практически весь спектр рисков: от «забыл файл на другом устройстве» до «сервер физически сгорел». Похожий трёхслойный подход к защите рабочих файлов разбирался и для другой профессии — в статье про версии чертежей конструктора на своём сервере те же принципы применены к САПР-файлам, и логика там переносится почти без изменений.

Что делать, если рукопись уже потеряна частично

Если вы читаете эту статью уже после того, как что-то пошло не так — часть текста пропала или перезаписалась — есть несколько практических шагов, прежде чем настраивать систему на будущее:

• Прекратите запись на тот же диск. Если файл удалён, а не перезаписан, шансы на восстановление специальными утилитами есть, но только пока диск не используется активно — новая запись может затереть удалённые данные физически.
• Проверьте корзину облачного сервиса. У Google Диска, Dropbox и большинства облаков есть история версий файла и корзина с более долгим сроком хранения, чем кажется на первый взгляд — иногда 30 дней и больше.
• Проверьте автосохранения текстового редактора. Многие редакторы держат временные файлы автосохранения в отдельной системной папке даже после того, как основной файл поврежден или удалён — стоит поискать по названию главы или по времени последнего изменения.
• После восстановления того, что удалось спасти — сразу настройте git и бэкап, чтобы повторная потеря стала физически невозможной, а не просто «маловероятной».

Такой опыт болезненный, но именно после него дисциплина версионирования перестаёт казаться избыточной предосторожностью и становится совершенно естественной частью рабочего процесса.

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