Как перенести интернет-магазин на новый VPS без потери заказов
Пошаговый план переезда интернет-магазина на новый VPS: резервная копия, тестовый запуск, финальная синхронизация, DNS, платёжные уведомления и откат.
В этой статье
Обычный сайт можно перенести ночью и проверить утром. Для интернет-магазина этого мало: пока копируются файлы и база, покупатели оформляют заказы, платёжные системы отправляют уведомления, 1С меняет остатки, а фоновые задачи формируют выгрузки.
Главный риск переезда — не несколько минут недоступности, а расхождение данных между старым и новым сервером. Поэтому перенос нужно проектировать как управляемое переключение с контрольной точкой и понятным откатом.
Составьте карту изменяемых данных
Перед работами перечислите всё, что меняется в реальном времени:
заказы, оплаты, статусы и возвраты;
корзины и пользовательские сессии;
остатки, цены и резервы;
новые аккаунты и адреса покупателей;
загруженные файлы, изображения и документы;
очереди писем, фоновые задания и обмен с 1С;
уведомления банков, служб доставки и маркетплейсов.
Эта карта определит способ финальной синхронизации. Однократной копии базы недостаточно, если старый сервер продолжает принимать записи.
Проверьте целевой VPS до копирования
Новый сервер должен быть совместим с приложением: версия операционной системы, веб-сервера, PHP, СУБД, расширений, планировщика и поискового движка. Для «1С-Битрикс: Управление сайтом» полезно заранее проверить окружение штатными средствами системы и сравнить настройки PHP, кодировку и часовой пояс.
Ресурсы выбирают по измерениям, а не только по числу товаров. Посмотрите пиковую нагрузку на процессор, использование памяти, размер и скорость роста базы, дисковые операции, фоновые задания и время формирования тяжёлых страниц. У VPS должен оставаться запас на индексацию, импорт и резервное копирование.
До переезда настройте обновления безопасности, отдельные учётные записи, межсетевой экран, TLS, мониторинг, журналирование и хранение резервных копий вне нового сервера.
Сделайте копию и обязательно восстановите её
Резервная копия считается рабочей только после пробного восстановления. Скопируйте базу данных, пользовательские файлы, конфигурацию приложения, задания cron, настройки веб-сервера и сведения о внешних интеграциях. Секреты не следует складывать в общий архив без шифрования и контроля доступа.
Разверните магазин на новом VPS под техническим адресом или локальной записью hosts. Закройте копию от покупателей и поисковых роботов, чтобы она не принимала реальные заказы и не попала в индекс.
На тестовой копии проверьте главную страницу, каталог, поиск, карточку товара, корзину, оформление заказа, личный кабинет и административную часть. Отдельно выполните тестовую отправку почты и запуск фоновых заданий.
Уменьшите окно изменений
За сутки или двое до переключения снизьте TTL DNS-записей, если это допускает текущая схема. Малый TTL не переносит сайт сам по себе и не гарантирует мгновенное обновление у всех провайдеров, но сокращает время жизни старого адреса в большинстве кэшей.
Основной объём файлов можно скопировать заранее, а перед переключением передать только изменения. Для базы выберите стратегию:
короткое окно обслуживания и финальный дамп;
репликация с последующим переключением;
временное прекращение операций записи;
прикладная синхронизация, если система поддерживает её и команда умеет контролировать конфликты.
Для большинства средних магазинов короткий режим обслуживания понятнее и безопаснее сложной двусторонней записи. Покупателю лучше увидеть честное сообщение несколько минут, чем оформить заказ в базу, которая больше не является основной.
Выполните финальное переключение по чек-листу
В начале окна остановите на старом сервере фоновые задания, импорт, обработку очередей и обмен с 1С. Запретите новые операции записи или включите режим обслуживания. Зафиксируйте последний номер заказа и время.
Сделайте финальную копию базы и изменившихся файлов, перенесите их, обновите конфигурацию подключения и запустите приложение на новом VPS. Только после проверки переключайте DNS, балансировщик или внешний IP.
На новом сервере убедитесь, что планировщик и очереди запущены ровно в одном месте. Если cron продолжит работать на двух серверах, магазин может дважды отправить письмо, списать остаток или передать заказ.
Проверьте путь заказа целиком
После переключения мало открыть главную страницу. Оформите контрольный заказ и пройдите его путь:
Товар добавляется в корзину с правильной ценой и остатком.
Заказ получает уникальный номер, следующий за последним боевым заказом.
Письмо или другое уведомление уходит один раз.
Платёжная система возвращает успешный статус на новый адрес.
Заказ передаётся в 1С или другую учётную систему.
Изменение статуса возвращается на сайт.
Служба доставки получает и возвращает данные.
Проверьте входящие webhooks. Некоторые внешние сервисы используют разрешённый IP, отдельный callback-адрес или подпись запроса. Смена сервера может нарушить интеграцию, даже если страницы сайта работают.
Не выключайте старый сервер сразу
Старый VPS следует перевести в режим, который не принимает заказы и не запускает фоновые задачи, но оставить доступным команде на согласованный срок. Логи старого и нового серверов помогут найти клиентов, которые ещё обращаются по прежнему адресу.
Заранее определите условия отката: критическая ошибка оплаты, потеря заказов, недоступность базы, превышение времени ответа. Откат — это не просто вернуть DNS. Нужно понять, появились ли на новом сервере записи, которых нет на старом, и как их безопасно перенести назад.
После стабилизации верните обычный TTL, обновите документацию, удалите временные доступы и проверьте новое резервное копирование. Через несколько дней выполните тест восстановления уже из копии нового VPS.
Успешный переезд измеряется не только временем доступности. Номера заказов непрерывны, оплаты сопоставлены, остатки согласованы, фоновые задания не дублируются, а у команды есть доказательство, что резервная копия действительно восстанавливается.
A standard website can be migrated overnight and checked in the morning. For an online store, that is not enough: while files and the database are being copied, customers are placing orders, payment systems are sending notifications, 1C is updating stock levels, and background tasks are generating exports.
The main risk of migration is not a few minutes of downtime, but data divergence between the old and new servers. Therefore, the migration must be designed as a controlled cutover with a checkpoint and a clear rollback procedure.
Map the data that changes
Before starting work, list everything that changes in real time:
orders, payments, statuses, and returns;
shopping carts and user sessions;
stock levels, prices, and reservations;
new accounts and customer addresses;
uploaded files, images, and documents;
email queues, background jobs, and 1C integration;
notifications from banks, delivery services, and marketplaces.
This map determines the final synchronization method. A one-time database copy is insufficient if the old server continues to accept records.
Check the target VPS before copying
The new server must be compatible with the application: operating system version, web server, PHP, database management system, extensions, scheduler, and search engine. For 1C-Bitrix: Site Management, it is useful to pre-check the environment using the system's built-in tools and compare PHP settings, encoding, and time zone.
Resources are selected based on metrics, not just the number of products. Review peak CPU load, memory usage, database size and growth rate, disk operations, background jobs, and the time required to generate heavy pages. The VPS must have headroom for indexing, imports, and backups.
Before the migration, configure security updates, separate user accounts, a firewall, TLS, monitoring, logging, and store backups outside the new server.
Create a copy and verify restoration
A backup is considered valid only after a test restoration. Copy the database, user files, application configuration, cron jobs, web server settings, and external integration details. Secrets should not be stored in an unencrypted archive without access control.
Deploy the store on a new VPS using a technical address or a local hosts entry. Block the copy from buyers and search engine crawlers so it does not accept real orders and is not indexed.
On the test copy, check the homepage, catalog, search, product card, cart, checkout, personal account, and admin panel. Additionally, test email delivery and background job execution.
Minimize the change window
One or two days before the switch, reduce the DNS TTL values if the current setup allows it. A low TTL does not move the site by itself and does not guarantee an instant update for all providers, but it shortens the lifespan of the old address in most caches.
You can copy the bulk of files in advance and transfer only the changes before the switch. For the database, choose a strategy:
short maintenance window with a final dump;
replication followed by a switch;
temporary suspension of write operations;
application-level synchronization if the system supports it and the team can manage conflicts.
For most medium-sized stores, a short maintenance mode is clearer and safer than complex bidirectional writing. It is better for a buyer to see an honest message for a few minutes than to place an order into a database that is no longer the primary one.
Execute the final switch according to the checklist
At the start of the maintenance window, stop background jobs, imports, queue processing, and 1C synchronization on the old server. Block new write operations or enable maintenance mode. Record the last order number and timestamp.
Create a final copy of the database and changed files, transfer them, update the connection configuration, and launch the application on the new VPS. Only switch DNS, load balancers, or external IPs after verification.
On the new server, ensure the scheduler and queues run in exactly one location. If cron continues running on both servers, the store may send duplicate emails, deduct stock twice, or process the same order twice.
Verify the entire order flow
After the switch, simply opening the homepage is not enough. Place a test order and follow its path:
The product is added to the cart with the correct price and stock level.
The order receives a unique number following the last live order.
The email or other notification is sent only once.
The payment system returns a successful status to the new endpoint.
The order is forwarded to 1C or another accounting system.
The status update is reflected on the website.
The delivery service receives and returns data.
Check incoming webhooks. Some external services use whitelisted IPs, dedicated callback addresses, or request signatures. Server migration can break integrations even if the website pages load correctly.
Do not shut down the old server immediately
The old VPS should be switched to a mode that rejects orders and stops background tasks, while remaining accessible to the team for an agreed period. Logs from both the old and new servers will help identify customers still accessing the old address.
Define rollback conditions in advance: critical payment errors, lost orders, database unavailability, or response time exceeding limits. A rollback is not just about reverting DNS. You must determine if any records exist on the new server that are missing from the old one, and how to safely move them back.
After stabilization, restore the standard TTL, update documentation, remove temporary access credentials, and verify the new backup system. A few days later, perform a recovery test using a copy from the new VPS.
A successful migration is measured not only by uptime. Order numbers must remain continuous, payments must align, inventory levels must match, background tasks must not duplicate, and the team must have proof that the backup can actually be restored.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.