На сервере есть папка с проектом. Рядом — папка backups. В ней аккуратные архивы по датам. Ночной скрипт отрабатывает, размер файлов растёт, в отчёте зелёная галочка. Можно выдохнуть: теперь у нас бэкапы.
Особенно удобно, что всё лежит на одном диске. Не нужно возиться с доступами к другому хранилищу, оплачивать лишнее место и ждать передачу по сети. Путь короткий. Почти семейный.
Я бы на этом месте задал один неприятный вопрос: что именно должно сломаться, чтобы мы воспользовались копией? От ответа зависит, сделали мы резервирование или просто навели порядок в каталогах.
Пусть оригинал и копия держатся вместе
Представим вполне будничную сцену. Накопитель перестал определяться. Сайт недоступен, база не стартует, человек за терминалом вспоминает про ночной архив. Отлично, сейчас восстановим.
Осталось прочитать его с накопителя, который перестал определяться.
Диск ничего не знает о наших названиях папок. Для него project и backups — соседние данные с одинаковыми шансами пережить физическую неисправность. Переименование второго каталога в backups_reliable не добавляет независимости.
Можно пойти дальше и выделить под копии отдельный раздел того же диска. В файловом менеджере он будет выглядеть самостоятельнее. Аппаратной поломке это впечатление передать не получится.
Другой диск — уже разговор, но ещё не вся история
Допустим, мы поставили второй накопитель. Теперь отказ первого не обязан уничтожить оба набора данных. Это реальное улучшение. Но оба диска всё ещё находятся в одном сервере и доступны одной системе.
Потеря машины целиком или доступ злоумышленника с достаточными правами способны задеть оба. Мне поэтому важнее список общих причин отказа, чем количество иконок дисков в панели.
Рабочая схема начинается с отдельного места хранения. Для важного проекта нужна копия за пределами этой машины, с продуманными правами удаления и историей версий. Доступ приложения к данным не должен автоматически давать возможность стереть все резервные поколения. Конкретный набор хранилищ выбирается под цену потери данных, а не под красоту схемы.
При этом скопировать живой каталог базы как обычную папку — ещё не значит получить согласованную базу. Для неё нужен подходящий способ резервирования; для загруженных файлов — понятная связь с состоянием данных. Иначе после восстановления записи о вложениях будут, а самих вложений не окажется.
Проверка, которую неудобно подделать галочкой
Я бы начал с простого упражнения: представить, что исходный сервер недоступен полностью. Есть новая машина. Где взять копию, ключи для расшифровки и инструкцию? Сколько последних изменений потеряется? Через какое время откроется сайт?
Потом действительно восстановить проект в отдельном окружении. Проверить вход, несколько записей, изображения и важную операцию. Не ограничиваться тем, что архив распаковался без ошибки.
Локальную копию после этого можно оставить — она удобная. Просто у неё появится правильная роль. А папка backups на единственном диске перестанет быть обещанием, которое этот диск никогда не давал.
