Бэкап сайта на shared-хостинге без cron CLI: bash, lftp и внешний триггер

Практическая схема бэкапа для сайта на shared-хостинге: bash-скрипт собирает дамп MySQL и архив файлов, отправляет их на внешний FTP через lftp, а запуск получает с VPS по SSH или из панели cron. Главная идея — не хранить резервную копию на том же аккаунте и регулярно проверять восстановление.

Скрипт лежит на хостинге выше public_html, запускается снаружи и пишет лог на стороне хостинга; при запуске с VPS можно дополнительно логировать сам SSH-триггер. Он делает mysqldump, упаковывает дамп вместе с файлами сайта в tar.gz, исключает кеши, .git и node_modules, загружает архив в отдельную FTP-папку и выполняет ротацию по KEEP=30.

Автор отказывается от rsync как от быстрого решения: без rsync-демона на принимающей стороне схема усложняется настройкой VPS и портов, тогда как lftp с обычным FTP обычно доступен на shared-хостингах. Панельные бэкапы критикуются за два типичных сценария: архив нужно скачивать вручную или он сохраняется на том же аккаунте, который может быть заблокирован вместе с сайтом.

Важные детали безопасности и надёжности: пароль MySQL лучше не передавать через -p, потому что аргументы команды видны другим пользователям shared-сервера; для InnoDB используется --single-transaction, для больших таблиц --quick, а tar получает --warning=no-file-changed, чтобы живой сайт не ломал мониторинг предупреждениями. Раз в месяц автор предлагает разворачивать последний архив локально в Docker, потому что в описанном опыте у двух клиентов из десяти первые бэкапы оказались нерабочими.

Коротко

  • Схема рассчитана на shared-хостинг без root, apt install, systemd и нормального доступа к crontab через CLI.
  • Архив включает файлы сайта и дамп базы, загружается на внешний FTP и хранится не на том же аккаунте, где работает сайт.
  • Внешний VPS с cron запускает скрипт по SSH; если VPS нет, можно использовать cron из панели хостинга без изменения скрипта.
  • Для mysqldump используются MYSQL_PWD, --single-transaction, --quick и utf8mb4; это снижает риски утечки пароля и неконсистентного дампа.
  • Проверка восстановления раз в месяц занимает 15–20 минут; в описанном опыте она помогла найти битые дампы и проблемы с правами файлов.

FAQ

Зачем выносить бэкап сайта с shared-хостинга на внешний FTP, если в панели уже есть кнопка резервного копирования?

Если архив хранится на том же аккаунте, блокировка или сбой аккаунта унесёт сайт и бэкап одновременно. Внешнее хранилище разрывает эту зависимость.

Почему для такой схемы выбран lftp, а не rsync, который часто используют для синхронизации файлов?

rsync быстро становится сложнее, если принимать данные должен VPS без готового rsync-демона. lftp работает через обычный FTP и чаще доступен на shared-хостингах без дополнительной настройки.

Как понять, что резервная копия действительно пригодна для восстановления, а не просто лежит на FTP?

Нужно регулярно скачивать последний архив и разворачивать его в тестовой среде. Автор описывает месячную проверку в Docker и полное восстановление на тестовый аккаунт раз в полгода.

Читайте также

  1. Как перенести расчёт абсолютных валютных курсов на Kaggle и автоматизировать обзоры через Gemini API
  2. ИИ-агенты для бизнеса в России: обзор 10 локальных платформ и решений
  3. Собственный видеохостинг на P2P и Fediverse: как развернуть PeerTube
  4. Cron в Linux: полное руководство для админов + скрытые проблемы
  5. Субагенты в Claude Code
Ключевые инсайты из новости (по версии ChatGPT)
  • Бэкап на shared-хостинге нужно хранить вне аккаунта сайта: Панельный бэкап, который сохраняется в папку того же хостинг-аккаунта, не защищает от блокировки аккаунта или проблем с самим хостингом. Для рабочих сайтов резервная копия должна уходить во внешнее хранилище, иначе сайт и архив могут стать недоступны одновременно.
    [Инфраструктура / Бэкапы]
Для получения полного доступа оформите подписку PubMag PRO.
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Инсайты автоматически генерируются с помощью искусственного интеллекта на основе текста статьи.
← Назад в лентуЧитать оригинал →
✈️ Подписывайтесь на мой Telegram-канал — там еще больше интересного про AdTech, MarTech, AI и многое другое!