Резервное копирование сайта по SSH

Что такое SSH в командной строке?

SSH (Secure Shell) — это защищённый протокол для удалённого управления сервером через командную строку. Коротко: это текстовый интерфейс для выполнения команд на удалённой машине. Он не предлагает графический интерфейс, зато даёт скорость, гибкость и возможности автоматизации, которые редко доступны в веб‑панелях.

Кому это полезно: админам, разработчикам, владельцам сайтов, которые хотят контроль над бэкапами и миграциями.

Важно: многие дешёвые shared‑хосты по умолчанию не дают SSH‑доступ, но VPS и выделенные серверы почти всегда дают. У некоторых провайдеров (например, GoDaddy) SSH включён или активируется в панели управления.

Как использовать SSH на вашем компьютере

Поддержка SSH есть в большинстве ОС:

• Windows: PowerShell (или клиент PuTTY)
• macOS: приложение Терминал
• Linux: Терминал и встроенный ssh

Откройте терминал и выполните команду ssh. Несколько полезных приёмов при вводе в командной строке:

• Нажимайте стрелки вверх/вниз, чтобы переключаться между предыдущими командами.
• Нажмите Tab для автодополнения имени файла или папки.
• Используйте сочетания Ctrl+C, Ctrl+L и Ctrl+R для управления вводом и поиском по истории.

Когда вы уверенно используете SSH, можно переходить к созданию резервных копий.

Вход на сервер по SSH

Запустите ваш SSH‑клиент и выполните одну из команд:

ssh username@yourdomain.com

или, если нужно подключиться по IP:

ssh username@YOUR.IP.ADDRESS.HERE

При запросе пароля в терминале вы не будете видеть вводимые символы — это нормальная мера безопасности.

После удачного входа вы увидите командную строку, например:

-bash-3.2:~$

Дальше можно осмотреться и перейти в веб‑директорию:

ls
cd directoryname
ls

Если корневая папка сайта называется httpd или public_html, войдите в неё:

cd httpd
ls

Резервное копирование базы данных через SSH

Для большинства сайтов на CMS вроде WordPress важны две части бэкапа: файлы и база данных. Для бэкапа базы данных нужна тройка сведений (в WordPress они находятся в файле wp‑config.php):

• имя базы данных
• имя пользователя базы данных
• пароль базы данных

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

Команда для создания дампа MySQL/MariaDB:

mysqldump --add-drop-table -u [username] -p [databasename] > [backupfilename].sql

Пояснения:

• –add-drop-table — добавляет DROP TABLE перед CREATE TABLE, что упрощает восстановление в чистую базу.
• -u — пользователь базы данных.
• -p — после этой опции будет запрошен пароль.

• [backupfilename].sql — перенаправляет вывод в файл с дампом.

После выполнения команды проверьте, что файл действительно создан командой ls.

Нет прямого доступа к базе данных по SSH

Иногда MySQL располагается на отдельном удалённом сервере и SSH‑доступ к нему недоступен (частая конфигурация на некоторых shared‑хостингах). В таких случаях используйте phpMyAdmin в панели хостинга для экспорта базы или настройте удалённый доступ к MySQL (требует дополнительных прав безопасности).

Резервное копирование файлов сайта через SSH

Когда база в виде SQL‑файла уже на сервере, создайте архив всех файлов сайта. Перейдите в папку, где хотите сохранить архив, и выполните:

tar -vcf yourbackupfilename.tar /directory/path

Пояснение параметров:

• tar — утилита архивации в Unix.
• -v — verbose, показывает прогресс.
• -c — создать архив.
• -f — указать имя файла архива.
• /directory/path — путь к директории сайта. Можно поставить точку (.) для архивирования текущей директории.

Важно: не используйте * если нужно включить скрытые файлы (например, .htaccess). Символ . (точка) включает все файлы текущей директории, включая скрытые.

После создания archives вы получите единый .tar файл, который можно скачать по FTP/SFTP или перенести на другой сервер.

Восстановление сайта из резервной копии через SSH

Если нужно восстановить файлы с архива:

tar -vxf yourbackupfilename.tar

Внимание: это перезапишет существующие файлы. Параметры:

• -x — извлечь файлы из архива.
• -v — показать процесс.
• -f — имя файла архива.

Восстановление базы данных:

1. Создайте пустую базу с тем же именем (или измените wp‑config.php на новые параметры).
2. Запустите импорт:

mysql -u [username] -p [databasename] < [databasebackupfilename].sql

После этого сайт должен вернуться в исходное состояние, если файлы и база соответствуют друг другу.

Когда этот метод не подходит

• У вас нет SSH‑доступа к хостингу.
• База находится на удалённом сервере без доступа через SSH; нужно использовать панель управления (phpMyAdmin) или настроить удалённый mysqldump.
• Очень большие сайты (>10 ГБ) могут требовать другого подхода (инкрементные бэкапы, потоковая передача через rsync, загрузка на объектное хранилище).

Альтернативные подходы

• Плагины для WordPress (UpdraftPlus, Duplicator) — удобны, но зависят от PHP/панели и могут быть медленнее.
• Снимки (snapshots) у провайдера VPS — быстрый способ отката всего сервера.
• rsync для инкрементных бэкапов и синхронизации с удалённым хранилищем.
• SCP или SFTP для прямой передачи архива на локальную машину или удалённый NAS.
• Интеграция с облачным хранилищем (S3, Backblaze) для хранения архивов вне дата‑центра.

Быстрый SOP — пошаговый плейбук

1. Подключитесь по SSH: ssh user@host
2. Перейдите в корень сайта: cd /path/to/site или cd httpd
3. Экспортируйте базу: mysqldump –add-drop-table -u user -p dbname > dbname-YYYYMMDD.sql
4. Создайте архив файлов: tar -vcf sitefiles-YYYYMMDD.tar .
5. Проверьте наличие файлов: ls -lh .sql .tar
6. Передайте архивы на безопасное хранилище (scp/rsync/облако).
7. Протестируйте восстановление в staging‑среде.

Краткая примечание: используйте метки даты в именах файлов для удобства (YYYYMMDD или YYYY-MM-DD).

Чеклист для ролей

• Владелец сайта:

  • Попросить резервную копию перед крупными изменениями.
  • Убедиться, что файлы и база переданы в безопасное место.

• Разработчик/админ:

  • Проверить версию PHP/базы и соответствие настроек.
  • Выполнить дамп базы и архив файлов.
  • Тестировать восстановление на staging.

• Контент‑менеджер:

  • Подтвердить, что контент корректно отображается после восстановления.

Шпаргалка команд (Cheat sheet)

# Вход
ssh user@host

# Просмотр текущей папки
pwd
ls -la

# Перемещение
cd /path/to/site

# Дамп базы
mysqldump --add-drop-table -u dbuser -p dbname > dbname-backup.sql

# Создание архива файлов
tar -vcf site-backup.tar /path/to/site
# или архив текущей директории
tar -vcf site-backup.tar .

# Распаковка архива (внимание: перезапись файлов)
tar -vxf site-backup.tar

# Восстановление базы
mysql -u dbuser -p dbname < dbname-backup.sql

# Передача архива на локальную машину
scp user@host:/path/to/site-backup.tar /local/path/

# Синхронизация (инкрементный бэкап)
rsync -avz --delete user@host:/path/to/site /local/backup/

Тесты и критерии приёмки

Критерии приёмки резервной копии:

• Файл дампа базы существует и непустой: размер > 0 и содержит строки CREATE TABLE/INSERT.
• Архив файлов создан и содержит ключевые файлы (index.php, wp‑config.php, .htaccess).
• Процесс восстановления на тестовой среде завершился без ошибок, сайт работает и отображает контент.

Как проверить:

• Откройте .sql файл в текстовом редакторе, убедитесь в наличии CREATE TABLE.
• Распакуйте tar в временную папку и проверьте наличие скрытых файлов.
• После восстановления зайдите на тестовый сайт и проверьте страницы, админ‑панель и загрузки.

Ошибки и устранение неполадок

• Ошибка доступа MySQL: проверьте правильность имени пользователя, базы и пароля; убедитесь, что у пользователя есть привилегии.
• Превышение лимита времени PHP или памяти: выполняйте дамп через SSH (не через веб‑интерфейс), используйте опции mysqldump для порционной выгрузки.
• Архив не содержит скрытых файлов: используйте точку (.) вместо * при создании архива.
• Ограничение размера файлов на FTP: используйте SCP/rsync или разделите архив на части с помощью split.

Риски и меры предосторожности

• Риск перезаписи: всегда проверяйте рабочую директорию и делайте резервную копию перед распаковкой.
• Хранение паролей в открытом виде: не оставляйте файлы с паролями на сервере без шифрования.
• Потеря данных при миграции: сначала тестируйте восстановление на staging.

Когда нужен более сложный подход

• Автоматизация: настройте cron‑задачи для регулярного создания дампов и передачи в удалённое хранилище.
• Инкрементные бэкапы: используйте rsync или специализированные утилиты резервного копирования.
• Большие базы и файлы: переносите дамп напрямую в облако (streaming) или делайте поблочную выгрузку.

Мини‑методология для безопасного бэкапа

1. Проводите холодные бэкапы (на время минимальной активности) для целостности данных.
2. Храните минимум две копии: локально и оффсайт (в облаке или на другом сервере).
3. Периодически тестируйте восстановление.
4. Ведите журнал операций с метками даты и описанием изменений.

Локальные особенности и советы по безопасности

• Если ваш хост поддерживает SFTP, используйте его вместо FTP для скачивания архивов.
• Для GoDaddy и аналогичных провайдеров проверьте, где расположены базы (локально или удалённо). В некоторых конфигурациях нужно экспортировать базу через панель управления.
• Шифруйте архивы при хранении вне сервера (gpg, openssl).

Резюме

Резервное копирование сайта через SSH — надёжный и быстрый метод для сохранения как файлов сайта, так и данных базы. Он требует базовых навыков работы с терминалом, но взамен даёт гибкость, контроль и возможность автоматизации. Регулярно делайте бэкапы, проверяйте их целостность и храните копии в безопасных местах.