Как перенести данные на новый диск без простоя

MAATRIX

Старый диск исчерпал ресурс, стал узким местом по скорости или вы просто решили перейти с HDD на SSD — и перед вами задача перенести данные на новый физический накопитель, пока сервер продолжает работать. Это не то же самое, что расширить существующий диск — там диск остаётся тем же самым устройством, просто у него меняются границы раздела. Здесь речь о другом накопителе: другом физическом устройстве, на которое нужно перенести данные и переключить на него всю нагрузку с минимальным простоем.

Чем перенос на новый диск отличается от расширения

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

• старый диск физически изнашивается (SMART показывает растущее число переназначенных секторов, растёт TBW на SSD) и вы хотите заменить его до отказа, а не после;
• меняется тип носителя — с HDD на SSD или с SATA SSD на NVMe — ради скорости, а расширение объёма тут ни при чём;
• старый диск слишком мал даже с учётом расширения раздела — например, физически нет способа увеличить его ёмкость, потому что диск не в RAID и не в LVM-группе со свободным местом;
• вы хотите физически вывести старый накопитель из эксплуатации (по гарантии, по плану замены оборудования, из-за приближающегося конца ресурса).

Во всех этих случаях задача не «увеличить существующее», а «переехать на другое устройство, не останавливая сервис надолго». План ниже написан именно под это.

Шаг 1: подключаем новый диск параллельно со старым

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

Правильный порядок — подключить новый диск параллельно со старым, пока оба физически в сервере одновременно. У подавляющего большинства современных серверов это возможно:

• на выделенном сервере — свободный SATA/SAS/NVMe-слот в корпусе (уточните заранее у провайдера, есть ли он и сколько стоит доустановка);
• на VPS — второй виртуальный диск через панель управления, который подключается «на лету» без перезагрузки в большинстве гипервизоров (KVM, ESXi, Proxmox);
• через внешний интерфейс — USB 3.0/eSATA как временная площадка, если свободного внутреннего слота физически нет (медленнее, но рабочий вариант для переноса и потом отключения).

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

lsblk

Новое устройство появится как отдельный /dev/sdb (или /dev/nvme1n1) рядом со старым /dev/sda. На нём нужно создать разметку и файловую систему — как на новом чистом диске:

parted /dev/sdb --script mklabel gpt mkpart primary 0% 100%
mkfs.ext4 /dev/sdb1

Если под данными у вас XFS, LVM или ZFS — создавайте те же типы структур, что и на старом диске, чтобы дальнейшее копирование и переключение прошли предсказуемо, без конвертации формата на лету.

Шаг 2: копируем основной объём данных заранее, пока старый диск работает

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

Смонтируйте новый диск во временную точку и запустите копирование с сохранением атрибутов:

mkdir -p /mnt/newdisk
mount /dev/sdb1 /mnt/newdisk

rsync -aHAX --info=progress2 /data/ /mnt/newdisk/

Разбор ключей rsync, которые здесь важны:

• -a — архивный режим (рекурсивно, с сохранением прав, владельца, времени модификации, символических ссылок);
• -H — сохраняет жёсткие ссылки как жёсткие ссылки, а не как отдельные копии файлов;
• -A — переносит ACL (расширенные права доступа), если они используются;
• -X — переносит extended attributes (например, user.* атрибуты, SELinux-контексты);
• --info=progress2 — показывает общий прогресс копирования, а не построчный вывод по каждому файлу (полезно на больших объёмах, чтобы не захламлять лог).

Первый прогон на активно используемых данных (десятки-сотни гигабайт) может идти часами — это нормально и ожидаемо, сервис в это время работает как обычно, простоя нет вообще. Пока идёт копирование, часть файлов на старом диске неизбежно изменится — новые записи, обновления, удаления. Это не проблема: rsync умеет докатывать только изменившееся, и вы запустите его повторно перед самим переключением.

Диск целиком или только данные: два разных инструмента

Здесь важно разделить два разных сценария, потому что для них нужны разные инструменты.

Если нужно перенести только конкретные данные — файлы приложения, базу данных, каталог с медиа, домашние директории пользователей — rsync полностью решает задачу. Вы точно знаете, что копируете, можете исключать ненужное (--exclude), можете проверять целостность после копирования.

Если нужно клонировать диск целиком, включая загрузочный раздел и операционную систему — например, вы физически меняете системный диск сервера — задача другая: нужен побайтовый (block-level) клон, а не копирование файлов поверх новой файловой системы. Для этого существуют специализированные инструменты клонирования дисков на уровне блоков (dd, clonezilla, partclone, коммерческие решения вроде Acronis) — они переносят диск целиком со всей структурой разделов, загрузчиком и метаданными файловой системы, а не пересобирают её заново через копирование файлов.

Смешивать подходы не стоит: пытаться скопировать загрузочный раздел через rsync — плохая идея (нужны специфические шаги с переустановкой загрузчика и правкой UUID в конфигах), а гонять dd ради переноса одной директории с данными — избыточно и медленно (копирует диск посекторно, включая пустое место). В большинстве практических случаев переноса данных на новом сервере или новом диске под данные вам нужен именно rsync — операционная система остаётся на месте, переезжает только то, что физически хранится на диске с данными.

Шаг 3: финальное окно — останавливаем запись и докатываем дельту

Когда основной объём уже перенесён и повторные прогоны rsync идут быстро (потому что копируют только изменения, а не весь массив заново), можно назначать короткое окно переключения. Это единственный этап, где сервис реально не пишет данные — и он должен быть максимально коротким и заранее отрепетированным.

Последовательность:

# 1. Останавливаем сервис, который пишет на старый диск
systemctl stop myapp

# 2. Финальная докатка дельты — она короткая, т.к. основной объём уже перенесён
rsync -aHAX --delete /data/ /mnt/newdisk/

# 3. Переключаем точку монтирования на новый диск
umount /mnt/newdisk
umount /data
mount /dev/sdb1 /data

# 4. Обновляем /etc/fstab, чтобы новый диск монтировался при перезагрузке
blkid /dev/sdb1
# добавить/заменить строку в /etc/fstab на UUID нового диска

# 5. Запускаем сервис обратно, уже на новом диске
systemctl start myapp

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

Само окно простоя здесь — это время между stop и start, и оно складывается из времени на финальную дельту (обычно секунды-минуты, если основной перенос уже сделан заранее) плюс время на переключение точки монтирования (секунды). Именно так простой сводится к минутам вместо часов на весь объём.

Проверка нового диска перед отключением старого

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

Что проверить перед тем, как трогать старый диск:

• сервис реально пишет и читает с нового устройства — lsblk или mount | grep /data должны показывать /dev/sdb1, а не старое устройство;
• контрольные суммы или хотя бы количество файлов и суммарный размер совпадают со старым диском (du -sh /data до и после, при необходимости — rsync -avn --delete в режиме dry-run как финальная сверка «ничего не потерялось»);
• приложение отработало реальные операции записи и чтения на новом диске без ошибок — не просто «запустилось», а прошло несколько реальных пользовательских сценариев;
• логи сервиса и системные логи (dmesg, journalctl -xe) не показывают ошибок ввода-вывода на новом устройстве.

Практический совет: не отключайте старый диск физически в тот же день. Оставьте его подключённым (можно размонтированным, но физически на месте) хотя бы на несколько дней — если что-то всплывёт не сразу (например, редкий сценарий записи, который не попал в первую проверку), у вас будет путь назад без экстренного восстановления из бэкапа. Это тот же принцип «не сжигать мосты сразу», что применяется в откате миграций баз и серверов.

Практические нюансы и грабли

Несколько вещей, которые стоит учесть до начала, а не после:

Отдельно про перенос по сети, если физического второго слота действительно нет: тот же rsync прекрасно работает через SSH —

rsync -aHAX --info=progress2 -e ssh /data/ user@new-server:/data/

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

Частые вопросы