Почему S3 идеально подходит именно для резервных копий
Бэкап не должен жить рядом с тем, что он спасает. Если сервер упал, диск умер или кто-то случайно удалил данные, локальная копия часто уходит вместе с проблемой. S3 решает это организационно: хранение отделяется от вычислений, загрузка автоматизируется, а доступ ограничивается так, чтобы бэкапы невозможно было “случайно” переписать или удалить.
3-2-1 без оверкилла: как сделать просто и надёжно
3-2-1 — это не про сложность, а про устойчивость: три копии, два разных носителя, одна копия вне основной точки. Для большинства сайтов достаточно:
-
рабочие данные на сервере;
-
короткая локальная история (1–3 дня) на сервере или на отдельной машине;
-
основная история в S3 с ротацией: например 7 дневных + 4 недельных + 6 месячных.
Главное — чтобы схема давала реальный ответ на вопрос: “за сколько минут/часов мы восстановимся и кто это делает”.
Бэкапы сайта в S3: WordPress, Laravel, статические сайты
Здоровая логика почти всегда одна: файлы + база.
WordPress
В WordPress обычно имеет смысл бэкапить wp-content (plugins/themes/uploads) и базу. Сам WordPress-core при необходимости восстанавливается быстро, а вот контент и настройки — нет.
Пример шаблона:
Laravel
В Laravel критично понимать, что именно нужно сохранять. Обычно это пользовательские загрузки и нужные директории storage/app (а не кэши и мусор). Дальше — дамп БД.
Статические сайты
Статика бэкапится проще всего: архив директории + отправка в S3. Если исходники живут в Git, иногда достаточно бэкапить только “контент” (build) и конфиги окружения.
Бэкап базы в S3: MySQL/PostgreSQL + шифрование + ротация
База — самое ценное, поэтому подход строгий: консистентный дамп, шифрование и управляемое хранение.
MySQL / MariaDB:
PostgreSQL:
Шифрование (GPG):
Ротация должна быть в двух местах. Локально — коротко, чтобы быстро откатываться. В S3 — по политике жизненного цикла, чтобы история была длинной, но не бесконечной.
rclone + S3: как сделать “облако как диск” и синхронизацию
rclone — это практичный швейцарский нож. Он хорош и для бэкапов, и для миграций, и для повседневной синхронизации.
Важно помнить: sync удаляет лишнее в целевом месте. Для бэкап-истории чаще безопаснее copy.
Если нужно “как диск”:
Borg/Restic + S3: дедупликация и быстрые инкременты
Когда бэкапов много, архивация “полным архивом каждый день” быстро становится дорогой. Borg/Restic решают это нормально: они делают дедупликацию и отправляют только изменения. Это экономит место и время, а восстановление становится более предсказуемым.
Пример с Restic:
Версионирование в S3 и “мусорные деньги”
Версионирование полезно, но оно любит незаметно раздувать объём: каждый перезаписанный файл создаёт новую версию, а старая остаётся лежать.
Чтобы не переплачивать:
-
включай версионирование там, где оно действительно нужно;
-
обязательно ставь lifecycle-правила на старые версии (например, хранить 14–30 дней и удалять);
-
следи за незавершёнными multipart-upload и delete markers;
-
разделяй префиксы/бакеты под разные типы данных, чтобы правила были прозрачными.
