Хостинг с ежедневными резервными копиями

При выборе хостинга с резервными копиями запросите правила для конкретного продукта. Копии shared-аккаунта, snapshot диска VPS и выгрузка базы решают разные задачи. Обещание на главной странице бренда нельзя переносить на все его услуги.

Для внешнего архива изучите S3-хранилище: API, закрытый доступ, версии объектов и проверку целостности. Versioning и сохранение файла в bucket не подтверждают независимый полный backup проекта.

Что входит в копию

PostgreSQL различает SQL-выгрузку, копирование на уровне файлов и непрерывное архивирование. У этих методов свои условия восстановления, описанные в официальной документации. Не выдавайте один вид копии за все три.

Дата, глубина хранения и допустимая потеря

Периодичность и срок хранения - разные свойства. «Ежедневно» не сообщает, сколько точек доступно, что происходит после удаления аккаунта и можно ли выбрать вчерашнюю копию. Попросите показать правило хранения, а не только кнопку backup.

RPO обозначает допустимую потерю изменений по времени, RTO - целевое время восстановления. Это требования вашего проекта, не измеренные здесь показатели провайдеров. Если магазин не может потерять несколько часов заказов, одной ежедневной выгрузки может быть мало. Нужна согласованная схема сохранения изменений и возврата данных.

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

Количество копий не календарный срок

На 6 октября 2026 года документация restic о retention различает keep-last и календарные keep-daily, keep-weekly, keep-monthly. keep-last сохраняет последние snapshots; keep-daily выбирает последний snapshot каждого дня, в котором копии вообще есть. Пропущенные дни не создают отсутствующую точку восстановления.

keep-within отсчитывает период от последнего snapshot, а не просто от текущего дня. По умолчанию политика применяется отдельно к группам host и paths. Несколько keep-правил объединяются по смыслу «сохранить при совпадении хотя бы одного»; одну копию нельзя посчитать несколько раз как разные ежедневную и недельную.

forget убирает snapshots, prune удаляет данные, которые больше не нужны сохраненным snapshots. Это разные этапы. Во время prune репозиторий блокируется и копии не могут завершиться. В документе есть dry-run для просмотра предполагаемых действий без удаления. Здесь ни forget, ни prune, ни dry-run на пользовательском хранилище не выполнялись.

Как выбрать глубину под ошибку, а не под лозунг

Термины backup, snapshot и RAID описывают разные свойства. Их наличие не дает автоматически одну и ту же историю восстановления.

Сначала определите, через какое время обычно замечают ошибку. Если повреждение обнаружено после смены нескольких копий, самая свежая может уже содержать проблему. Нужен возврат к подходящей старой точке, а не просто наличие сегодняшнего архива.

Не задавайте срок только ради уменьшения диска. Сначала сверяйте список доступных точек, состав архива и возможность восстановить старую дату отдельно. Для внешнего хранения подтвердите права доступа и период: обещание панели не заменяет условия назначения.

Это критерии выбора, не предложение удалить старые архивы и не универсальная норма числа дней. Рабочие изображения, файлы и копии сохраняются. Изменение retention-политики требует отдельного согласованного плана и проверки последствий.

Как сверить состав базы

Для PostgreSQL pg_dump создает согласованную выгрузку одной базы; роли и другие глобальные объекты требуют отдельного учета. Пользовательские файлы приложения в эту выгрузку не входят. После переноса проверьте владельцев и права, а не только список таблиц.

Для MySQL у mysqldump режим single-transaction связан с транзакционными таблицами. Его нельзя считать универсальной защитой для всех движков и параллельных изменений схемы. Если состав базы неизвестен, запросите метод копирования у администратора вместо запуска случайной команды на рабочем магазине.

Владелец сайта должен знать, кто выполняет восстановление: он сам, поддержка или привлеченный специалист. Если нужен root-доступ, инструкция для shared-панели не подойдет. Подробный маршрут вынесен в руководство по бэкапу сайта.

Проверка возврата без риска для заказов

Восстанавливайте в отдельную среду, не поверх рабочего сайта. Отключите реальные платежи, отправку писем, внешние webhooks и задания расписания. Архив может содержать действующие ключи интеграций; доступ к тестовой копии нужно ограничить.

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

Какие условия уже известны в каталоге

В локальной выборке, проверенной 5 октября 2026 года, Timeweb shared заявляет ежедневные копии с хранением 30 дней. Для SpaceWeb shared подтверждено заявление о ежедневных копиях, но глубина неизвестна; в выбранных VPS SpaceWeb backup был выключен и предлагался платно. Ссылки и оговорки находятся в обзорах Timeweb и SpaceWeb.

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

Перед переносом сохраните независимую копию с отдельными доступами и проведите один возврат на тестовую среду. Если нет способа забрать данные при закрытии аккаунта, предложение еще не готово к выбору.