Перенос VPS сервера без потери данных: пошаговая инструкция

<p><script type="application/ld+json"><span style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" data-mce-type="bookmark" class="mce_SELRES_start"></span> { "@context": "https://schema.org", "@type": "HowTo", "name": "Перенос VPS сервера без потери данных", "description": "Пошаговый перенос VPS на другой сервер через rsync и дамп базы данных без остановки сайта и потери данных.", "totalTime": "PT3H", "step": [ {"@type": "HowToStep", "name": "Инвентаризация", "text": "Составь список того, что переносишь: файлы сайта, базы данных, конфиги, cron, сертификаты."}, {"@type": "HowToStep", "name": "Подготовка нового VPS", "text": "Установи те же версии ПО, что на старом сервере, создай пользователей и настрой SSH-доступ."}, {"@type": "HowToStep", "name": "Перенос файлов", "text": "Скопируй файлы через rsync по SSH с сохранением прав и владельцев."}, {"@type": "HowToStep", "name": "Перенос базы данных", "text": "Сделай дамп базы и перелей его на новый сервер через SSH-канал."}, {"@type": "HowToStep", "name": "Финальная синхронизация", "text": "Останови запись на старом сервере и досинхронизируй изменения за время переноса."}, {"@type": "HowToStep", "name": "Проверка", "text": "Проверь работу сайта на новом сервере через подмену hosts до переключения DNS."}, {"@type": "HowToStep", "name": "Переключение DNS", "text": "Смени A-запись на IP нового сервера и дождись обновления резолвинга."} ] } </script></p>

"Быстрый

<br /> Перенос VPS сервера без потери данных делается в три этапа: копируешь файлы через rsync по SSH с сохранением прав, переносишь базу данных через дамп (mysqldump или pg_dump), а на финальном шаге останавливаешь запись на старом сервере и досинхронизируешь разницу перед переключением DNS. Простоя при таком подходе можно избежать почти полностью — данные не теряются, потому что ты не удаляешь старый сервер, пока не убедился, что новый работает идентично.<br />

<h2>1. Диагноз</h2> <p>Старый VPS доживает последние дни. Или хостер поднял цены. Или ты наконец решил свалить с виртуалки на 1 ядре куда-то, где сайт не падает от трёх одновременных посетителей. Причина неважна — важно, что перенос VPS сервера без потери данных нужен тебе прямо сейчас, а не «когда-нибудь разберусь».</p> <p>Знакомая картина: скопировал файлы через FTP, забыл про базу, забыл про cron, забыл про права на директории — и через час в чате техподдержки хостера летят гневные сообщения от клиента. Так делать не будем.</p> <p>Что получишь на выходе: рабочий сайт на новом сервере, старый сервер целый и невредимый на случай отката, и ни одной потерянной записи в базе. Время на перенос — от 40 минут для простого сайта-визитки до 3-4 часов для проекта с большой базой и кучей мелких сервисов.</p> <p>Понадобится:</p> <ul> <li>root-доступ к обоим серверам по SSH</li> <li><a title="SSH-ключи: подключение без пароля — полный гайд для Linux, Windows и macOS" href="https://it-apteka.com/ssh-kljuchi-podkljuchaemsja-bez-parolja-i-ne-panikuem/" target="_blank" rel="noopener" data-wpil-monitor-id="3390">SSH-ключ или пароль</a> root на новом VPS</li> <li>доступ к <a class="wpil_keyword_link" title="DNS" href="https://it-apteka.com/tag/dns/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="3346">DNS</a>-зоне домена</li> <li>окно на финальную синхронизацию (обычно 5-15 минут простоя записи, не всего сайта)</li> </ul> <p>В статье разберём: почему перенос обычно идёт не по плану, пошаговый рецепт через rsync и дамп базы, проверку результата, типичные ошибки с решениями, альтернативные способы переноса и что делать после, чтобы не наступить на те же грабли через полгода.</p> <h2>2. Причины, по которым перенос VPS обычно ломается</h2> <p>Прежде чем лезть в консоль, разберись, откуда растут ноги у большинства проблем при переносе сервера. Тогда рецепт из раздела 3 будет не набором магических команд, а понятным алгоритмом.</p> <table> <tbody> <tr> <th>Причина</th> <th>Почему ломает перенос</th> </tr> <tr> <td>Разные версии ПО на старом и новом сервере</td> <td>PHP 8.3 против PHP 7.4, <a class="wpil_keyword_link" title="MySQL" href="https://it-apteka.com/tag/mysql/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="3350">MySQL</a> 8 против MariaDB 10.6 — синтаксис базы или расширения могут не совпасть, сайт падает с 500-й ошибкой</td> </tr> <tr> <td>Копирование файлов без остановки записи</td> <td>Пока rsync копирует, в базу или в файлы продолжают писать — часть изменений теряется между стартом копирования и финальным переключением</td> </tr> <tr> <td>Забытые cron-задачи</td> <td>crontab привязан к пользователю на конкретной машине, при переносе файлов сайта он никуда не копируется автоматически</td> </tr> <tr> <td>TTL DNS-записи выставлен на сутки</td> <td>Часть пользователей продолжает попадать на старый сервер часами после переключения, вводит в заблуждение при проверке</td> </tr> <tr> <td>Потерянные права доступа и владельцы файлов</td> <td>rsync без нужных флагов копирует файлы от имени текущего пользователя, веб-сервер теряет доступ к загруженным файлам</td> </tr> <tr> <td>SSL-сертификат привязан к старому IP</td> <td>Let’s Encrypt хранит challenge-файлы и конфиг в конкретных путях — при простом копировании сертификат может не подхватиться корректно</td> </tr> <tr> <td>Забытая почта и SPF/PTR-записи</td> <td>Новый IP сервера ещё не имеет репутации, письма с него улетают в спam, если заранее не настроить обратную DNS-запись</td> </tr> </tbody> </table> <p>Ни одна из этих причин не фатальна сама по себе. Фатально их игнорировать.</p> <h2>3. Рецепт</h2> <h3>Подготовка</h3> <p>Зависимости: SSH-клиент на локальной машине или прямой доступ с одного VPS на другой, rsync на обоих серверах, доступ к панели управления DNS-зоной.</p> <table> <tbody> <tr> <th>Компонент</th> <th>Актуальная версия на момент публикации</th> </tr> <tr> <td>rsync</td> <td>3.4.3</td> </tr> <tr> <td>rclone (для облачных хранилищ, опционально)</td> <td>1.75.0</td> </tr> <tr> <td>OS нового сервера</td> <td>та же мажорная версия, что на старом, либо новее (Ubuntu 22.04/24.04, <a class="wpil_keyword_link" title="Debian" href="https://it-apteka.com/tag/debian/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="3349">Debian</a> 12)</td> </tr> </tbody> </table>

"Проверь

<br /> Перед установкой любого компонента проверь свежие релизы в официальных репозиториях. Версии rsync и rclone обновляются с патчами безопасности, а старая версия rsync может не поддерживать нужные флаги дельта-передачи.<br />

<p>Проверь среду на новом сервере: сколько свободного места, какая версия ядра, доступен ли SSH по ключу.</p> <pre><code class="language-bash"> df -h uname -r ssh -T root@NEW_SERVER_IP </code></pre> <h3>Архитектура переноса</h3> <pre class="mermaid">%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ffffff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#94a3b8', 'lineColor': '#64748b', 'fontSize': '15px', 'fontFamily': 'ui-sans-serif, system-ui, sans-serif' }, 'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50} }}%% flowchart TD A["Старый VPS"] --> B["rsync по SSH"] B --> C["Новый VPS"] A --> D["Дамп базы данных"] D --> C C --> E["Проверка через hosts"] E --> F["Переключение DNS"] F --> G["Клиент"] style A fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412 style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d style E fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af style G fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af </pre> <h3>Шаг 1. Инвентаризация</h3> <p>Составь список того, что реально переносишь. Не «сайт», а конкретно: путь к файлам, имя базы, пользователь БД, cron-задачи, SSL-сертификаты, конфиги веб-сервера.</p> <pre><code class="language-bash"> crontab -l -u www-data ls -la /etc/nginx/sites-enabled/ mysql -e "SHOW DATABASES;" ls /etc/letsencrypt/live/ </code></pre> <p>Результат: текстовый файл-чеклист, который не даст забыть половину сервиса на середине переноса.</p> <h3>Шаг 2. Установка одинакового ПО на новом сервере</h3> <p>Ставь те же мажорные версии, что на старом сервере. Не MySQL 8, если на старом MariaDB 10.6 — это разные диалекты, дамп может не залиться без правок.</p> <pre><code class="language-bash"> apt update && apt install -y nginx mariadb-server php8.1-fpm php8.1-mysql unzip systemctl status nginx mariadb php8.1-fpm </code></pre> <p>Результат: чистая связка на новом сервере, которая готова принять файлы и базу без конфликтов версий.</p> <h3>Шаг 3. Перенос файлов через rsync</h3> <p>rsync выигрывает у scp и FTP по одной причине — он копирует дельту, а не всё заново при повторном запуске. Первый прогон может идти долго, повторные — минуты.</p> <pre><code class="language-bash"> rsync -avz --progress -e "ssh -p 22" \ /var/www/site/ root@NEW_SERVER_IP:/var/www/site/ </code></pre> <p>Флаг <code>-a</code> сохраняет права, владельцев и симлинки. Без него получишь сайт, который открывается, но веб-сервер не может писать в загрузки.</p> <p>Результат: файлы на новом сервере с сохранёнными правами доступа, идентичные оригиналу.</p> <h3>Шаг 4. Дамп и перенос базы данных</h3> <p>Дамп базы гоняем напрямую через SSH-канал, без промежуточного файла на диске — быстрее и не забивает место.</p> <pre><code class="language-bash"> mysqldump -u root -p --single-transaction --routines --triggers site_db | \ ssh root@NEW_SERVER_IP "mysql -u root -p site_db" </code></pre> <p>Флаг <code>--single-transaction</code> критичен для InnoDB <a title="ARP MikroTik: настройка, таблица, proxy-arp и reply-only — полный разбор" href="https://it-apteka.com/arp-mikrotik-nastrojka-tablica-proxy-arp-i-reply-only-polnyj-razbor/" target="_blank" rel="noopener" data-wpil-monitor-id="3360">—</a> он делает консистентный снимок без блокировки таблиц на запись. Без него на нагруженной базе получишь рассинхрон между таблицами.</p> <p>Для PostgreSQL логика та же:</p> <pre><code class="language-bash"> pg_dump -U postgres site_db | ssh root@NEW_SERVER_IP "psql -U postgres site_db" </code></pre> <p>Результат: <a title="Linux SIP прокси сервер: полное руководство по Kamailio, OpenSIPS и Asterisk" href="https://it-apteka.com/linux-sip-proksi-server-polnoe-rukovodstvo-po-kamailio-opensips-i-asterisk/" target="_blank" rel="noopener" data-wpil-monitor-id="3352">полная копия базы на новом сервере</a>, включая хранимые процедуры и триггеры.</p> <h3>Шаг 5. Перенос конфигов, cron и сертификатов</h3> <p>Конфиг <a title="Nginx против Apache: какой веб-сервер выбрать в 2026 году" href="https://it-apteka.com/nginx-protiv-apache-kakoj-veb-server-vybrat-v-2026-godu/" target="_blank" rel="noopener" data-wpil-monitor-id="3358">nginx или Apache</a> копируй отдельно, а не вместе с файлами сайта — там прописаны абсолютные пути и, возможно, старый IP.</p> <pre><code class="language-bash"> rsync -avz /etc/nginx/sites-available/site.conf root@NEW_SERVER_IP:/etc/nginx/sites-available/ crontab -l -u www-data > cron_backup.txt scp cron_backup.txt root@NEW_SERVER_IP:/tmp/ </code></pre> <p>На новом сервере:</p> <pre><code class="language-bash"> crontab -u www-data /tmp/cron_backup.txt ln -s /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/ nginx -t </code></pre> <p>SSL-сертификат проще не копировать, а выпустить заново через <a title="Автоматизация SSL для десятков доменов через acme.sh и DNS API (без Certbot)" href="https://it-apteka.com/avtomatizacija-ssl-dlja-desjatkov-domenov-cherez-acme-sh-i-dns-api-bez-certbot/" target="_blank" rel="noopener" data-wpil-monitor-id="3356">certbot после переключения DNS</a> — так надёжнее, чем тащить приватный ключ вручную между серверами.</p> <h3>Шаг 6. Финальная синхронизация</h3> <p>Вот тут решается, будет ли потеря данных или нет. Логика простая: между первым прогоном rsync и переключением DNS проходит время, за которое на старом сервере что-то поменялось. Значит, нужен второй, короткий прогон прямо перед переключением.</p>

"Критично

<br /> Перед финальной синхронизацией переведи сайт в режим только для чтения или временно отключи запись в базу. Иначе изменения, сделанные пользователями в последние минуты, могут не попасть в финальный дамп.<br />

<pre><code class="language-bash"> rsync -avz --delete -e ssh /var/www/site/ root@NEW_SERVER_IP:/var/www/site/ mysqldump -u root -p --single-transaction site_db | \ ssh root@NEW_SERVER_IP "mysql -u root -p site_db" </code></pre> <p>Этот прогон занимает секунды-минуты, потому что копирует только дельту. Именно поэтому окно простоя — 5-15 минут, а не часы.</p> <h3>Шаг 7. Проверка на новом сервере до переключения DNS</h3> <p>Проверяй сайт на новом IP, подменив hosts на <a title="Qwen3 Coder Next: бесплатный ИИ для кодинга локально — установка, CLI и сравнение агентов 2026" href="https://it-apteka.com/qwen3-coder-next-besplatnyj-ii-dlja-kodinga-lokalno-ustanovka-cli-i-sravnenie-agentov-2026/" target="_blank" rel="noopener" data-wpil-monitor-id="3355">локальной машине —</a> так убедишься, что всё работает, ещё не трогая боевой DNS.</p> <pre><code class="language-bash"> echo "NEW_SERVER_IP example.com" | sudo tee -a /etc/hosts curl -I -H "Host: example.com" http://NEW_SERVER_IP </code></pre> <p><a title="Браузер по умолчанию для ссылки в Windows: как открыть сайт не в том браузере, который назначен системой" href="https://it-apteka.com/brauzer-po-umolchaniju-dlja-ssylki-v-windows-kak-otkryt-sajt-ne-v-tom-brauzere-kotoryj-naznachen-sistemoj/" target="_blank" rel="noopener" data-wpil-monitor-id="3351">Открой сайт в браузере</a>, полистай ключевые страницы, проверь форму обратной связи и админку. Если что-то не так — правь сейчас, пока <a title="Настройка NTP MikroTik: клиент, сервер и всё что ломается без него" href="https://it-apteka.com/nastrojka-ntp-na-mikrotik-klient-i-server-shpargalka-dlja-ros-6-i-7/" target="_blank" rel="noopener" data-wpil-monitor-id="3353">клиенты идут на старый сервер</a>.</p> <h3>Шаг 8. Переключение DNS</h3> <p>За сутки-двое до переноса снизь TTL A-записи до 300 секунд — это сократит время «размытого» состояния, когда часть пользователей видит старый сервер, часть новый.</p> <pre><code class="language-bash"> dig +short example.com </code></pre> <p>Меняешь A-запись на IP нового сервера в панели DNS-провайдера, ждёшь обновления резолвинга по всему миру.</p> <pre class="mermaid">%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#f8fafc', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#94a3b8', 'noteBkgColor': '#fefce8', 'noteTextColor': '#713f12', 'noteBorderColor': '#fbbf24', 'actorBkg': '#f8fafc', 'actorBorder': '#94a3b8', 'actorTextColor': '#1e293b', 'fontSize': '15px', 'fontFamily': 'ui-sans-serif, system-ui, sans-serif' }, 'sequence': { 'mirrorActors': false, 'messageAlign': 'center', 'actorMargin': 120, 'width': 160, 'noteMargin': 12 } }}%% sequenceDiagram participant U as Пользователь participant D as DNS participant O as Старый VPS participant N as Новый VPS U->>D: Запрос IP example.com D->>U: Отдаёт новый IP U->>N: Запрос страницы N->>U: Ответ 200 OK Note over O: Остаётся резервом на пару дней </pre> <h3>Шаг 9. Мониторинг после переключения</h3> <p>Первые часы после переключения — самые нервные. Смотри логи в <a title="7 Docker-контейнеров, которые реально изменили мой домашний сервер" href="https://it-apteka.com/7-docker-kontejnerov-kotorye-realno-izmenili-moj-domashnij-server/" target="_blank" rel="noopener" data-wpil-monitor-id="3359">реальном времени и не убирай старый сервер</a>.</p> <pre><code class="language-bash"> tail -f /var/log/nginx/access.log tail -f /var/log/nginx/error.log </code></pre> <p>Держи старый VPS живым минимум 3-5 дней. Если что-то всплывёт — сможешь откатиться за минуты, а не поднимать всё с нуля.</p> <h2>4. Проверка</h2> <p>После переноса гоняй не только «сайт открылся», а полный набор проверок.</p> <pre><code class="language-bash"> systemctl status nginx mariadb php8.1-fpm nginx -t mysqlcheck -u root -p --all-databases curl -o /dev/null -s -w "%{http_code}\n" https://example.com </code></pre> <p>Сравни контрольные суммы ключевых файлов на старом и новом сервере — это дешёвая страховка от «половина файлов не докопировалась».</p> <pre><code class="language-bash"> rsync -avzn --checksum -e ssh /var/www/site/ root@NEW_SERVER_IP:/var/www/site/ </code></pre> <p>Флаг <code>-n</code> — это dry-run, ничего не изменит, только покажет расхождения. Пустой вывод значит, что файлы идентичны.</p> <h2>5. Осложнения</h2> <table> <tbody> <tr> <th>Ошибка</th> <th>Причина</th> <th>Решение</th> </tr> <tr> <td>После переключения DNS часть пользователей видит старый сайт</td> <td>Не снижен TTL заранее, DNS-кэш провайдеров</td> <td>Подожди до истечения старого TTL, проверь резолвинг из разных точек</td> </tr> <tr> <td>502 Bad Gateway на новом сервере</td> <td>PHP-FPM не запущен или сокет прописан неверно в конфиге nginx</td> <td>Проверь путь до сокета и статус сервиса</td> </tr> <tr> <td>Сайт открывается, но админка выдаёт 500</td> <td>Разные версии PHP, отсутствует нужное расширение</td> <td>Сравни список модулей PHP на старом и новом сервере</td> </tr> <tr> <td>Загруженные файлы (картинки, документы) не открываются</td> <td>rsync скопировал их с правами текущего пользователя, а не веб-сервера</td> <td>Пересчитай владельца директории</td> </tr> <tr> <td>Cron-задачи перестали выполняться</td> <td>crontab не был перенесён для нужного пользователя</td> <td>Импортируй сохранённый crontab</td> </tr> <tr> <td>Почта с сайта улетает в спам</td> <td>Новый IP без репутации, не настроена PTR-запись</td> <td>Запроси у хостера обратную DNS-запись, добавь SPF и DKIM</td> </tr> <tr> <td>SSL-сертификат невалиден на новом сервере</td> <td>Сертификат привязан к старому пути или домену challenge не прошёл</td> <td>Перевыпусти сертификат через certbot после переключения DNS</td> </tr> </tbody> </table> <pre><code class="language-bash"> chown -R www-data:www-data /var/www/site/uploads certbot --nginx -d example.com </code></pre> <p>Всё не так плохо, как ты думаешь. Всё намного хуже — если пропустил шаг 6 и не сделал финальную синхронизацию. Тогда часть данных теряется навсегда, и никакой troubleshooting это уже не починит.</p> <h2>6. Альтернативы</h2> <p>rsync и дамп базы — не единственный способ. Вот другие варианты и почему в большинстве случаев выигрывает именно этот.</p> <table> <tbody> <tr> <th>Способ</th> <th>Когда подходит</th> <th>Минус</th> </tr> <tr> <td>Снапшот/образ от хостера</td> <td>Перенос внутри одного хостинг-провайдера, идентичное окружение</td> <td>Не работает между разными хостерами и гипервизорами, часто без гарантии консистентности базы</td> </tr> <tr> <td>Блочное клонирование диска (dd, partclone)</td> <td>Полностью идентичное железо и разметка диска</td> <td>Требует <a title="VPN на MikroTik: полный гайд 2026 — WireGuard, L2TP/IPsec, IKEv2, настройка сервера и клиента" href="https://it-apteka.com/vpn-na-mikrotik-polnyj-gajd-2026-wireguard-l2tp-ipsec-ikev2-nastrojka-servera-i-klienta/" target="_blank" rel="noopener" data-wpil-monitor-id="3357">полной остановки сервера</a> на время клонирования, не гибок при смене ОС или размера диска</td> </tr> <tr> <td>rclone</td> <td>Перенос статики через промежуточное облачное хранилище</td> <td>Лишний посредник для обычного переезда между двумя VPS, оправдан только при переносе через S3-совместимое хранилище</td> </tr> <tr> <td>Плагины миграции CMS (для WordPress и подобных)</td> <td>Простой сайт-визитка без кастомного кода</td> <td>Плохо работает с большими базами и нестандартной структурой файлов</td> </tr> </tbody> </table> <p>rsync плюс дамп базы выигрывает по совокупности: работает между разными хостерами, разными ОС, разными версиями дисков, даёт контроль над каждым шагом и позволяет докопировать только изменения на финальном этапе. Именно поэтому это базовый рецепт, а не просто один из вариантов.</p> <h2>7. Профилактика</h2> <p>Перенос закончился — не расслабляйся.</p> <ul> <li>Настрой <a class="wpil_keyword_link" title="Мониторинг" href="https://it-apteka.com/category/monitoring/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="3348">мониторинг</a> нового сервера (Zabbix, Netdata или простой uptime-чекер) в первый же день</li> <li>Сделай резервную копию сразу после переноса — например, через BorgBackup, чтобы не начинать историю бэкапов с нуля</li> <li>Проверь автозапуск всех сервисов после перезагрузки</li> <li>Убедись, что новый сервер защищён так же, как старый — а лучше строже</li> <li>Не удаляй старый VPS минимум неделю, даже если очень хочется сэкономить</li> <li>Обнови DNS-записи MX и SPF, если почта тоже переехала</li> <li>Проверь, что <a title="Бэкап и восстановление сервера The Dude (MikroTik)" href="https://it-apteka.com/bjekap-i-vosstanovlenie-servera-the-dude-mikrotik/" target="_blank" rel="noopener" data-wpil-monitor-id="3391">бэкапы с нового сервера</a> уходят в отдельное хранилище, а не остаются локально</li> </ul> <p>Капля никотина убивает лошадь. Одна забытая cron-задача с бэкапом — весь архив данных за полгода.</p> <h3>Безопасность нового сервера</h3> <ul> <li>UFW — закрой всё, кроме нужных портов, сразу после установки</li> <li>fail2ban — на SSH и на веб-формы входа</li> <li>SSH hardening <a title="SSH-ключи: подключение без пароля — полный гайд для Linux, Windows и macOS" href="https://it-apteka.com/ssh-kljuchi-podkljuchaemsja-bez-parolja-i-ne-panikuem/" target="_blank" rel="noopener" data-wpil-monitor-id="3354">— отключи вход по паролю</a>, смени порт, запрети root-логин напрямую</li> <li>Отдельный пользователь БД с правами только на нужную базу, без доступа ко всем базам сразу</li> <li>Регулярные резервные копии, вынесенные за пределы самого сервера</li> <li>Ограничение доступа к админ-панелям по IP, где это возможно</li> </ul> <pre><code class="language-bash"> ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable apt install fail2ban -y systemctl enable fail2ban </code></pre> <h3>Резервное копирование</h3> <table> <tbody> <tr> <th>Что бэкапить</th> <th>Как часто</th> <th>Куда</th> </tr> <tr> <td>Файлы сайта</td> <td>Ежедневно</td> <td>Отдельное хранилище, не тот же диск</td> </tr> <tr> <td>База данных</td> <td>Ежедневно, при высокой нагрузке — чаще</td> <td>Отдельное хранилище + off-site копия</td> </tr> <tr> <td>Конфиги сервисов</td> <td>После каждого значимого изменения</td> <td><a class="wpil_keyword_link" title="Git" href="https://it-apteka.com/tag/git/" target="_blank" rel="noopener" data-wpil-keyword-link="linked" data-wpil-monitor-id="3347">Git</a>-репозиторий или отдельное хранилище</td> </tr> </tbody> </table> <p>Восстановление проверяй руками хотя бы раз в квартал — бэкап, который никогда не разворачивали, это не бэкап, а файл, который занимает место.</p> <h3>Таблица портов</h3> <table> <tbody> <tr> <th>Порт</th> <th>Протокол</th> <th>Назначение</th> <th>Доступен снаружи?</th> </tr> <tr> <td>22</td> <td>TCP</td> <td>SSH-доступ, используется для rsync и передачи дампа</td> <td>Да, с ограничением по IP или ключом</td> </tr> <tr> <td>80</td> <td>TCP</td> <td>HTTP, редирект на HTTPS</td> <td>Да</td> </tr> <tr> <td>443</td> <td>TCP</td> <td>HTTPS</td> <td>Да</td> </tr> <tr> <td>3306</td> <td>TCP</td> <td>MySQL/MariaDB, нужен только при прямом удалённом подключении к базе</td> <td>Нет, только localhost или через SSH-туннель</td> </tr> </tbody> </table> <h3>Обновление после переноса</h3> <p>Обновляй систему на новом сервере сразу после стабилизации, но не в день переноса — дай сервису отработать пару дней без изменений.</p> <pre><code class="language-bash"> apt update && apt list --upgradable apt upgrade -y </code></pre> <p>Перед обновлением проверь список пакетов, которые оно затронет, и сделай снапшот или бэкап конфигов. Если после обновления что-то сломалось — откатывайся на зафиксированный бэкап, а не гадай на кофейной гуще, какой пакет виноват.</p> <h2>8. FAQ</h2> <p><strong>Как перенести VPS без остановки сайта?</strong><br /> Полностью без простоя перенести можно только при парном (blue-green) развёртывании с балансировщиком. В типовом сценарии простой сводится к 5-15 минутам на финальную синхронизацию базы данных — этого времени достаточно для копирования дельты, а не всего объёма заново.</p> <p><strong>Сколько времени занимает перенос VPS сервера?</strong><br /> Для небольшого сайта с базой до нескольких гигабайт — 30-60 минут суммарно. Для проекта с большой базой и множеством сервисов — от 2 до 4 часов, включая проверку и переключение DNS.</p> <p><strong>Как проверить, что перенос VPS прошёл без потери данных?</strong><br /> Сравни контрольные суммы файлов через rsync с флагом —checksum в режиме dry-run, проверь количество записей в ключевых таблицах базы командой SELECT COUNT(*), сверь размер директорий на старом и новом сервере.</p> <p><strong>Что делать, если после переноса VPS сайт не открывается?</strong><br /> Проверь статус nginx и PHP-FPM, посмотри error.log, убедись, что резолвинг DNS уже обновился на твоей машине. В большинстве случаев причина — не докопированный конфиг веб-сервера или расхождение версий PHP.</p> <p><strong>Чем перенос через rsync отличается от переноса через снапшот хостера?</strong><br /> Снапшот копирует весь диск целиком и работает только внутри одного хостера с совместимым гипервизором. rsync копирует файлы на уровне файловой системы, работает между любыми серверами и ОС, и позволяет докопировать только изменившиеся файлы на финальном шаге.</p> <p><strong>Нужно ли менять пароли и SSH-ключи после переноса на новый VPS?</strong><br /> Да. Перенос — хороший повод сгенерировать новую пару SSH-ключей для нового сервера и не тащить старые пароли по инерции. Заодно <a title="Новости гаджетов апрель 2026 — первоисточники и как проверить каждую новинку" href="https://it-apteka.com/novosti-gadzhetov-aprel-2026-pervoistochniki-i-kak-proverit-kazhduju-novinku/" target="_blank" rel="noopener" data-wpil-monitor-id="3393">проверь список пользователей с доступом —</a> часто там остаются забытые аккаунты трёхлетней давности.</p> <h2>9. Прогноз</h2> <p>Файлы перенесены через rsync с сохранением прав, база данных перелита дампом с финальной досинхронизацией, DNS переключён на новый IP. Старый <a title="VPN на MikroTik: полный гайд 2026 — WireGuard, L2TP/IPsec, IKEv2, настройка сервера и клиента" href="https://it-apteka.com/vpn-na-mikrotik-polnyj-gajd-2026-wireguard-l2tp-ipsec-ikev2-nastrojka-servera-i-klienta/" target="_blank" rel="noopener" data-wpil-monitor-id="3392">сервер стоит рядом как страховка —</a> трогать его не нужно, пока новый не отработает несколько дней без сюрпризов.</p> <p>Дальше — рутина: мониторинг, регулярные бэкапы, обновления по расписанию. Если что-то пошло не так после переноса — пиши в комментарии, разберёмся вместе.</p>

Быстрый ответ

Перенос VPS сервера без потери данных делается в три этапа: копируешь файлы через rsync по SSH с сохранением прав, переносишь базу данных через дамп (mysqldump или pg_dump), а на финальном шаге останавливаешь запись на старом сервере и досинхронизируешь разницу перед переключением DNS. Простоя при таком подходе можно избежать почти полностью — данные не теряются, потому что ты не удаляешь старый сервер, пока не убедился, что новый работает идентично.

Содержание: показать

1. Диагноз

Старый VPS доживает последние дни. Или хостер поднял цены. Или ты наконец решил свалить с виртуалки на 1 ядре куда-то, где сайт не падает от трёх одновременных посетителей. Причина неважна — важно, что перенос VPS сервера без потери данных нужен тебе прямо сейчас, а не «когда-нибудь разберусь».

Знакомая картина: скопировал файлы через FTP, забыл про базу, забыл про cron, забыл про права на директории — и через час в чате техподдержки хостера летят гневные сообщения от клиента. Так делать не будем.

Что получишь на выходе: рабочий сайт на новом сервере, старый сервер целый и невредимый на случай отката, и ни одной потерянной записи в базе. Время на перенос — от 40 минут для простого сайта-визитки до 3-4 часов для проекта с большой базой и кучей мелких сервисов.

Понадобится:

root-доступ к обоим серверам по SSH
SSH-ключ или пароль root на новом VPS
доступ к DNS-зоне домена
окно на финальную синхронизацию (обычно 5-15 минут простоя записи, не всего сайта)

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

2. Причины, по которым перенос VPS обычно ломается

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

Причина	Почему ломает перенос
Разные версии ПО на старом и новом сервере	PHP 8.3 против PHP 7.4, MySQL 8 против MariaDB 10.6 — синтаксис базы или расширения могут не совпасть, сайт падает с 500-й ошибкой
Копирование файлов без остановки записи	Пока rsync копирует, в базу или в файлы продолжают писать — часть изменений теряется между стартом копирования и финальным переключением
Забытые cron-задачи	crontab привязан к пользователю на конкретной машине, при переносе файлов сайта он никуда не копируется автоматически
TTL DNS-записи выставлен на сутки	Часть пользователей продолжает попадать на старый сервер часами после переключения, вводит в заблуждение при проверке
Потерянные права доступа и владельцы файлов	rsync без нужных флагов копирует файлы от имени текущего пользователя, веб-сервер теряет доступ к загруженным файлам
SSL-сертификат привязан к старому IP	Let’s Encrypt хранит challenge-файлы и конфиг в конкретных путях — при простом копировании сертификат может не подхватиться корректно
Забытая почта и SPF/PTR-записи	Новый IP сервера ещё не имеет репутации, письма с него улетают в спam, если заранее не настроить обратную DNS-запись

Ни одна из этих причин не фатальна сама по себе. Фатально их игнорировать.

3. Рецепт

Подготовка

Зависимости: SSH-клиент на локальной машине или прямой доступ с одного VPS на другой, rsync на обоих серверах, доступ к панели управления DNS-зоной.

Компонент	Актуальная версия на момент публикации
rsync	3.4.3
rclone (для облачных хранилищ, опционально)	1.75.0
OS нового сервера	та же мажорная версия, что на старом, либо новее (Ubuntu 22.04/24.04, Debian 12)

Проверь перед стартом

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

Проверь среду на новом сервере: сколько свободного места, какая версия ядра, доступен ли SSH по ключу.


df -h
uname -r
ssh -T root@NEW_SERVER_IP

Архитектура переноса

Шаг 1. Инвентаризация

Составь список того, что реально переносишь. Не «сайт», а конкретно: путь к файлам, имя базы, пользователь БД, cron-задачи, SSL-сертификаты, конфиги веб-сервера.


crontab -l -u www-data
ls -la /etc/nginx/sites-enabled/
mysql -e "SHOW DATABASES;"
ls /etc/letsencrypt/live/

Результат: текстовый файл-чеклист, который не даст забыть половину сервиса на середине переноса.

Шаг 2. Установка одинакового ПО на новом сервере

Ставь те же мажорные версии, что на старом сервере. Не MySQL 8, если на старом MariaDB 10.6 — это разные диалекты, дамп может не залиться без правок.


apt update && apt install -y nginx mariadb-server php8.1-fpm php8.1-mysql unzip
systemctl status nginx mariadb php8.1-fpm

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

Шаг 3. Перенос файлов через rsync

rsync выигрывает у scp и FTP по одной причине — он копирует дельту, а не всё заново при повторном запуске. Первый прогон может идти долго, повторные — минуты.


rsync -avz --progress -e "ssh -p 22" \
  /var/www/site/ root@NEW_SERVER_IP:/var/www/site/

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

Результат: файлы на новом сервере с сохранёнными правами доступа, идентичные оригиналу.

Шаг 4. Дамп и перенос базы данных

Дамп базы гоняем напрямую через SSH-канал, без промежуточного файла на диске — быстрее и не забивает место.


mysqldump -u root -p --single-transaction --routines --triggers site_db | \
  ssh root@NEW_SERVER_IP "mysql -u root -p site_db"

Флаг --single-transaction критичен для InnoDB — он делает консистентный снимок без блокировки таблиц на запись. Без него на нагруженной базе получишь рассинхрон между таблицами.

Для PostgreSQL логика та же:


pg_dump -U postgres site_db | ssh root@NEW_SERVER_IP "psql -U postgres site_db"

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

Шаг 5. Перенос конфигов, cron и сертификатов

Конфиг nginx или Apache копируй отдельно, а не вместе с файлами сайта — там прописаны абсолютные пути и, возможно, старый IP.


rsync -avz /etc/nginx/sites-available/site.conf root@NEW_SERVER_IP:/etc/nginx/sites-available/
crontab -l -u www-data > cron_backup.txt
scp cron_backup.txt root@NEW_SERVER_IP:/tmp/

На новом сервере:


crontab -u www-data /tmp/cron_backup.txt
ln -s /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/
nginx -t

SSL-сертификат проще не копировать, а выпустить заново через certbot после переключения DNS — так надёжнее, чем тащить приватный ключ вручную между серверами.

Шаг 6. Финальная синхронизация

Вот тут решается, будет ли потеря данных или нет. Логика простая: между первым прогоном rsync и переключением DNS проходит время, за которое на старом сервере что-то поменялось. Значит, нужен второй, короткий прогон прямо перед переключением.

Критично для нулевой потери данных

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


rsync -avz --delete -e ssh /var/www/site/ root@NEW_SERVER_IP:/var/www/site/
mysqldump -u root -p --single-transaction site_db | \
  ssh root@NEW_SERVER_IP "mysql -u root -p site_db"

Этот прогон занимает секунды-минуты, потому что копирует только дельту. Именно поэтому окно простоя — 5-15 минут, а не часы.

Шаг 7. Проверка на новом сервере до переключения DNS

Проверяй сайт на новом IP, подменив hosts на локальной машине — так убедишься, что всё работает, ещё не трогая боевой DNS.


echo "NEW_SERVER_IP example.com" | sudo tee -a /etc/hosts
curl -I -H "Host: example.com" http://NEW_SERVER_IP

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

Шаг 8. Переключение DNS

За сутки-двое до переноса снизь TTL A-записи до 300 секунд — это сократит время «размытого» состояния, когда часть пользователей видит старый сервер, часть новый.


dig +short example.com

Меняешь A-запись на IP нового сервера в панели DNS-провайдера, ждёшь обновления резолвинга по всему миру.

Шаг 9. Мониторинг после переключения

Первые часы после переключения — самые нервные. Смотри логи в реальном времени и не убирай старый сервер.


tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

Держи старый VPS живым минимум 3-5 дней. Если что-то всплывёт — сможешь откатиться за минуты, а не поднимать всё с нуля.

4. Проверка

После переноса гоняй не только «сайт открылся», а полный набор проверок.


systemctl status nginx mariadb php8.1-fpm
nginx -t
mysqlcheck -u root -p --all-databases
curl -o /dev/null -s -w "%{http_code}\n" https://example.com

Сравни контрольные суммы ключевых файлов на старом и новом сервере — это дешёвая страховка от «половина файлов не докопировалась».


rsync -avzn --checksum -e ssh /var/www/site/ root@NEW_SERVER_IP:/var/www/site/

Флаг -n — это dry-run, ничего не изменит, только покажет расхождения. Пустой вывод значит, что файлы идентичны.

5. Осложнения

Ошибка	Причина	Решение
После переключения DNS часть пользователей видит старый сайт	Не снижен TTL заранее, DNS-кэш провайдеров	Подожди до истечения старого TTL, проверь резолвинг из разных точек
502 Bad Gateway на новом сервере	PHP-FPM не запущен или сокет прописан неверно в конфиге nginx	Проверь путь до сокета и статус сервиса
Сайт открывается, но админка выдаёт 500	Разные версии PHP, отсутствует нужное расширение	Сравни список модулей PHP на старом и новом сервере
Загруженные файлы (картинки, документы) не открываются	rsync скопировал их с правами текущего пользователя, а не веб-сервера	Пересчитай владельца директории
Cron-задачи перестали выполняться	crontab не был перенесён для нужного пользователя	Импортируй сохранённый crontab
Почта с сайта улетает в спам	Новый IP без репутации, не настроена PTR-запись	Запроси у хостера обратную DNS-запись, добавь SPF и DKIM
SSL-сертификат невалиден на новом сервере	Сертификат привязан к старому пути или домену challenge не прошёл	Перевыпусти сертификат через certbot после переключения DNS


chown -R www-data:www-data /var/www/site/uploads
certbot --nginx -d example.com

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

6. Альтернативы

rsync и дамп базы — не единственный способ. Вот другие варианты и почему в большинстве случаев выигрывает именно этот.

Способ	Когда подходит	Минус
Снапшот/образ от хостера	Перенос внутри одного хостинг-провайдера, идентичное окружение	Не работает между разными хостерами и гипервизорами, часто без гарантии консистентности базы
Блочное клонирование диска (dd, partclone)	Полностью идентичное железо и разметка диска	Требует полной остановки сервера на время клонирования, не гибок при смене ОС или размера диска
rclone	Перенос статики через промежуточное облачное хранилище	Лишний посредник для обычного переезда между двумя VPS, оправдан только при переносе через S3-совместимое хранилище
Плагины миграции CMS (для WordPress и подобных)	Простой сайт-визитка без кастомного кода	Плохо работает с большими базами и нестандартной структурой файлов

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

7. Профилактика

Перенос закончился — не расслабляйся.

Настрой мониторинг нового сервера (Zabbix, Netdata или простой uptime-чекер) в первый же день
Сделай резервную копию сразу после переноса — например, через BorgBackup, чтобы не начинать историю бэкапов с нуля
Проверь автозапуск всех сервисов после перезагрузки
Убедись, что новый сервер защищён так же, как старый — а лучше строже
Не удаляй старый VPS минимум неделю, даже если очень хочется сэкономить
Обнови DNS-записи MX и SPF, если почта тоже переехала
Проверь, что бэкапы с нового сервера уходят в отдельное хранилище, а не остаются локально

Капля никотина убивает лошадь. Одна забытая cron-задача с бэкапом — весь архив данных за полгода.

Безопасность нового сервера

UFW — закрой всё, кроме нужных портов, сразу после установки
fail2ban — на SSH и на веб-формы входа
SSH hardening — отключи вход по паролю, смени порт, запрети root-логин напрямую
Отдельный пользователь БД с правами только на нужную базу, без доступа ко всем базам сразу
Регулярные резервные копии, вынесенные за пределы самого сервера
Ограничение доступа к админ-панелям по IP, где это возможно


ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
apt install fail2ban -y
systemctl enable fail2ban

Резервное копирование

Что бэкапить	Как часто	Куда
Файлы сайта	Ежедневно	Отдельное хранилище, не тот же диск
База данных	Ежедневно, при высокой нагрузке — чаще	Отдельное хранилище + off-site копия
Конфиги сервисов	После каждого значимого изменения	Git-репозиторий или отдельное хранилище

Восстановление проверяй руками хотя бы раз в квартал — бэкап, который никогда не разворачивали, это не бэкап, а файл, который занимает место.

Таблица портов

Порт	Протокол	Назначение	Доступен снаружи?
22	TCP	SSH-доступ, используется для rsync и передачи дампа	Да, с ограничением по IP или ключом
80	TCP	HTTP, редирект на HTTPS	Да
443	TCP	HTTPS	Да
3306	TCP	MySQL/MariaDB, нужен только при прямом удалённом подключении к базе	Нет, только localhost или через SSH-туннель

Обновление после переноса

Обновляй систему на новом сервере сразу после стабилизации, но не в день переноса — дай сервису отработать пару дней без изменений.


apt update && apt list --upgradable
apt upgrade -y

Перед обновлением проверь список пакетов, которые оно затронет, и сделай снапшот или бэкап конфигов. Если после обновления что-то сломалось — откатывайся на зафиксированный бэкап, а не гадай на кофейной гуще, какой пакет виноват.

8. FAQ

Как перенести VPS без остановки сайта?
Полностью без простоя перенести можно только при парном (blue-green) развёртывании с балансировщиком. В типовом сценарии простой сводится к 5-15 минутам на финальную синхронизацию базы данных — этого времени достаточно для копирования дельты, а не всего объёма заново.

Сколько времени занимает перенос VPS сервера?
Для небольшого сайта с базой до нескольких гигабайт — 30-60 минут суммарно. Для проекта с большой базой и множеством сервисов — от 2 до 4 часов, включая проверку и переключение DNS.

Как проверить, что перенос VPS прошёл без потери данных?
Сравни контрольные суммы файлов через rsync с флагом —checksum в режиме dry-run, проверь количество записей в ключевых таблицах базы командой SELECT COUNT(*), сверь размер директорий на старом и новом сервере.

Что делать, если после переноса VPS сайт не открывается?
Проверь статус nginx и PHP-FPM, посмотри error.log, убедись, что резолвинг DNS уже обновился на твоей машине. В большинстве случаев причина — не докопированный конфиг веб-сервера или расхождение версий PHP.

Чем перенос через rsync отличается от переноса через снапшот хостера?
Снапшот копирует весь диск целиком и работает только внутри одного хостера с совместимым гипервизором. rsync копирует файлы на уровне файловой системы, работает между любыми серверами и ОС, и позволяет докопировать только изменившиеся файлы на финальном шаге.

Нужно ли менять пароли и SSH-ключи после переноса на новый VPS?
Да. Перенос — хороший повод сгенерировать новую пару SSH-ключей для нового сервера и не тащить старые пароли по инерции. Заодно проверь список пользователей с доступом — часто там остаются забытые аккаунты трёхлетней давности.

9. Прогноз

Файлы перенесены через rsync с сохранением прав, база данных перелита дампом с финальной досинхронизацией, DNS переключён на новый IP. Старый сервер стоит рядом как страховка — трогать его не нужно, пока новый не отработает несколько дней без сюрпризов.

Дальше — рутина: мониторинг, регулярные бэкапы, обновления по расписанию. Если что-то пошло не так после переноса — пиши в комментарии, разберёмся вместе.

Author: Поп Растрига

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →

Поделитесь: