Как организовать миграцию данных самостоятельно

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

Акцентируем внимание на настройке надежного резервного копирования в инструкции. Иногда требуется перенести только определенные файлы, чтобы начать работу в облачном сервере, поэтому наша инструкция предлагает сначала перенести резервные копии необходимых данных. Далее мы рассмотрим пример миграции сайта с одного сервера на другой, охватывая шаги от резервного копирования до восстановления данных. И проиллюстрируем этот процесс на примере миграции базы данных MySQL.

В чём заключается апгрейд?

Рассказываем, как можно настроить резервное копирование на несколько разных площадок, в том числе и на публичные сервисы, разберём на примере Google Диск.

В чём разница между миграцией и резервным копированием?

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

Далее по тексту коллеги используют аббревиатуры:

• РК БД - резервное копирование, резервная копия базы данных.
• Миграция данных - перенос данных с одного сервера на другой.
• СУБД - система управления базы данных, для примера: MySQL, PostgreSQL.

Пример переноса данных с одного сервера на другой

Рассмотрим пример, когда требуется выполнить перенос сайта с одного сервера на другой. Шаги по миграции данных будут следующими:

1. Выполнить РК базы данных и файлов сайта;
2. Миграция данных;
3. Восстановление данных.

Вводные данные:

• Сервер под управлением Debian 12.

Шаг 1: Резервное копирование базы данных MySQL

Самый просто и быстрый вариант, это сделать РК БД с помощью mysqldump.

mysqldump -u username -p db > file.sql

Ключи к команде mysqludmp:

u - имя пользователя базы данных,

p - название базы данных,

> file.sql - название файла куда будет скопирована база данных.

Примечание:

1. Для создания нескольких копий используйте следующую команду:

mysqldump -u username -p --databases db1 db2 db3 > test.sql

2. Для копирования всех существующих баз:

mysqldump -u username -p --all-databases > test.sql

3. Рекомендуем использовать учётную запись для доступа к БД отличную от root.

4. Можете сделать выгрузку через phpMyAdmin или любой другой WebUI к СУБД.

Шаг 2: Миграция файлов и базы данных на удаленный сервер

В нашем примере, выполняем копирование данных с одного сервера на другой сервер. Можете выполнить миграцию данных, как для файлов, так и для резервной копии базы данных.

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

apt install rsync

Возможности rsync:

• Позволяет выполнить синхронизацию и копирование файлов между серверами, папками.
• Синхронизация только измененных данных без копирования уже существующих файлов - актуально при переносе директорий upload и подобных, в которую пользователи загружают свои файлы.

Примечание:

1. Мы рассмотрим ситуацию, в которой wordpress находится в директории /var/www/wordpress.
2. Отметим, что rsync выдаст ошибку, если конечной директории не существует. Директория /var/www создается автоматически при установке веб-сервера.

Перейдите в /var/www и выполните следующую команду:

rsync -a wordpress root@192.168.88.22:/var/www/

Можете дополнительно использовать следующие ключи:

• a (archive) - сжатие данных перед отправкой;
• z (compress) - сжатие данных во время передачи данных;
• v (verbose) - просмотр отладочной информации при синхронизации (debug).

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

Автоматизация резервного копирования

Выполним автоматизацию создания резервных копий с хранением данных на удаленном сервере. Для этого используем следующий сценарий:

• Создание и хранение копий локально - БД (текущая неделя, 7 дней глубина хранения).
• Архивное хранение на удалённом сервере (текущая и предыдущая неделя, 14 дней глубина хранения).
• Резервная копия виртуальной машины (текущая неделя, 7 дней глубина хранения).

Шаг 1. Ежедневное резервное копирование всех баз данных MySQL с глубиной хранения 7 дней.

1. Создаём следующий файл с названием backup.sh и вставляем содержимое:

#!/bin/bash
CURRENTDATE=$(date +"%Y%m%d")
BACKUP_DIR="/backup/mysql/"

MYSQL=/usr/bin/mysql
MYSQLDUMP=/usr/bin/mysqldump

MYSQL_USER="USERNAME"
MYSQL_PASSWORD="PASSWORD"
SKIPDATABASES="Database|information_schema|performance_schema|mysql"

RETENTION_POLICY=7

mkdir -p $BACKUP_DIR/$CURRENTDATE

databases=`$MYSQL -u$MYSQL_USER -p$MYSQL_PASSWORD -e "SHOW DATABASES;" | 
grep -Ev "($SKIPDATABASES)"`

for db in $databases; do
echo $db
$MYSQLDUMP --force --opt --user=$MYSQL_USER -p$MYSQL_PASSWORD --skip-
lock-tables --events --databases $db | gzip > "$BACKUP_DIR/$CURRENTDATE/$db.sql.gz"
done

find $BACKUP_DIR/* -mtime +$RETENTION_POLICY -delete

backup.sh - выполнение резервного копирования в папку /backup/mysql/

2. Выставляем права на исполнение файла:

chmod +x backup.sh

3. Откроем cron (crontab -e) и добавляем следующее правило:

0 0 * * * /backup/backup.sh

С подробным описанием работы и валидатором cron можете ознакомиться на данном сайте.

Кратко рассмотрим:

• MYSQL_USER, MYSQL_PASSWORD - укажите данные для подключения к базе данных. Учетная запись должна иметь доступ к БД.
• SKIPDATABASES - пропускаем РК системных БД.
• RETENTION_POLICY - указываем глубину хранения в точках, мы выполняем РК раз в сутки, поэтому указываем 7 точек, т.е. 7 дней.
• 0 0 * * * - запускаем выполнение скрипта каждый день в 00:00.

Шаг 2. Копирование данных на Google Диск с глубиной хранения 14 дней.

1. Копирование данных будем выполнять с помощью rsync, но с дополненным функционалом для бесплатных облачных платформах, таких как Google Диск.
2. Приложение называется rclone, выполним установку:

curl https://rclone.org/install.sh | sudo bash

       3. Добавим конфигурацию Google Диск.

rclone config

4.Создадим новую удалённую точку, клавишей N (New remote) и присвоим имя, например, google-drive.

5. Теперь настроим следующие параметры:

• client_id и client_secret - оставьте пустыми
• scope - выберите 1 (Full access)
• root_folder-id, service_account_file - оставьте пустым
• edit advanced config - n
• Use web browser … - n

На экране должна появиться команда, которую нужно будет запустить на локальном компьютере (предварительно скачав его).

Выполнив команду у вас откроется браузер для входа в ваш Google аккаунт для подключения rclone к Google Диск, по завершению вы получите токен для связи rclone и ваш Google Диск.

6. Теперь копируем данные в папку backups на Google Диск:

/usr/bin/rclone copy "/root/wordpress.tar.gz" "google-drive:/backups/wordpress.tar.gz"

7. В завершении настроим глубину хранений 14 дней, т.е. файлы старше 15 дней будут удалены.

/usr/bin/rclone delete “google-drive”:”/backups/” --min-age 15d -v --dry-run

Наши итоговые рекомендации:

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

1. резервное копирование с глубиной хранения от 7 дней,
2. хранение копий на разных устройствах и машинных залах: одна копия храния на сервер РК, вторая копия находится на системе хранения данных, которая размещена в другом машинном зале,
3. настроим оптимальный план резервного копирования и восстановления данных,
4. ежедневные отчёты для вас о выполненных заданиях резервного копирования.