Chuyển hosting không gián đoạn: quy trình 7 bước an toàn
Chuyển hosting không gián đoạn: hạ TTL, sao chép dữ liệu, thử server mới qua file hosts, chuẩn bị SSL, đồng bộ lần cuối và đổi DNS mà khách không hề hay biết.

Ý chính
- Gián đoạn khi chuyển hosting gần như luôn đến từ DNS, SSL và dữ liệu ghi dở, không phải từ việc chép file.
- Hạ TTL xuống 300 giây trước ít nhất bằng TTL cũ, thường là 24 đến 48 giờ.
- Thử website trên server mới bằng file hosts hoặc curl --resolve trước khi đổi DNS.
- Giữ server cũ chạy ít nhất 48 giờ sau khi đổi DNS để đón các truy cập còn sót lại.
Chuyển hosting không gián đoạn là hoàn toàn làm được: bạn dựng bản sao website trên server mới, kiểm tra nó khi server cũ vẫn phục vụ khách, rồi mới đổi bản ghi DNS. Trong suốt quá trình, luôn có ít nhất một server trả lời đúng. Mấu chốt nằm ở ba thứ: TTL của DNS phải được hạ từ trước, chứng chỉ SSL phải sẵn sàng trên server mới, và dữ liệu phát sinh trong lúc chuyển (đơn hàng, bình luận, email) không được rơi mất.
Bài này đi qua quy trình 7 bước, dùng được cho một website lẫn cả server: mỗi bước có cách làm thủ công với lệnh cụ thể, và cách làm với ZoPanel.
Vì sao chuyển hosting hay bị gián đoạn?
Việc chép file và database hiếm khi gây sự cố. Gián đoạn thường đến từ những chỗ người ta không để ý:
| Nguyên nhân | Biểu hiện | Cách tránh |
|---|---|---|
| TTL DNS cao (ví dụ 86400 giây) | Một phần khách vẫn vào server cũ suốt cả ngày | Hạ TTL trước 24 đến 48 giờ |
| Server mới chưa có SSL | Trình duyệt báo lỗi chứng chỉ ngay sau khi đổi DNS | Cài chứng chỉ trước khi đổi DNS |
| Dữ liệu ghi vào server cũ sau khi sao chép | Mất đơn hàng, bình luận, tài khoản mới | Đóng băng ghi và đồng bộ lần cuối |
| Quên bản ghi AAAA (IPv6) | Người dùng IPv6 vẫn vào server cũ, hoặc lỗi kết nối | Sửa hoặc xoá AAAA cùng lúc với A |
| Đổi nameserver cùng lúc với đổi IP | Phải chờ tới 48 giờ, không rút lại được nhanh | Tách hai việc ra, làm riêng từng bước |
| Email đến server cũ trong lúc chuyển | Thư "biến mất" khỏi hộp thư mới | Đồng bộ hộp thư sau khi đổi MX |
Nếu bạn xử lý hết sáu dòng này, khách truy cập sẽ không thấy gì cả.
Bước 1: Kiểm kê trước khi chuyển
Ghi ra mọi thứ website đang dùng trên server cũ:
- Tên miền và tên miền phụ, kể cả alias, subdomain và bản ghi
www. - Toàn bộ bản ghi DNS hiện tại: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, mã xác minh Google/Facebook), SRV. Chụp lại hoặc xuất ra file.
- Database và user database, phiên bản PHP, các extension PHP đặc biệt.
- Cron job, tác vụ chạy nền, worker hàng đợi.
- Email: số hộp thư, dung lượng, forwarder.
- Những chỗ ghi cứng IP của server cũ: file cấu hình ứng dụng, whitelist ở cổng thanh toán, API bên thứ ba, firewall của đối tác.
Dòng cuối hay bị quên nhất: cổng thanh toán chỉ nhận callback từ IP cũ có thể làm hỏng thanh toán trong khi website trông vẫn bình thường.
Bước 2: Hạ TTL của DNS từ trước
TTL là thời gian các DNS resolver (của nhà mạng, Google, Cloudflare...) được phép nhớ một bản ghi. Nếu bản ghi A đang có TTL 86400 giây (1 ngày), sau khi bạn đổi IP, một số người dùng có thể vẫn được dẫn về server cũ tới 24 giờ.
Xem TTL hiện tại:
dig +noall +answer example.com A
dig +noall +answer example.com MX
Cột số thứ hai là TTL còn lại tính bằng giây. Hạ TTL của A, AAAA và MX xuống 300 giây tại nơi đang quản lý DNS, và làm việc này trước thời điểm chuyển ít nhất bằng TTL cũ: TTL cũ 1 ngày thì hạ trước ít nhất 1 ngày, an toàn hơn là 48 giờ. Nếu hạ TTL ngay trước khi đổi IP, resolver vẫn còn giữ bản ghi cũ với TTL dài.
Một lưu ý quan trọng: đổi bản ghi A khác với đổi nameserver. Đổi bản ghi A chỉ phụ thuộc TTL bạn tự đặt. Đổi nameserver tại nhà đăng ký thì phụ thuộc TTL của vùng cha: với .com, bản ghi NS do registry trả về có TTL 172800 giây (48 giờ), và bạn không hạ được con số này. Nếu cần chuyển cả DNS sang nhà cung cấp mới, hãy làm thành hai đợt: đợt một chép nguyên các bản ghi sang nameserver mới (vẫn trỏ về server cũ) rồi đổi nameserver và chờ 48 giờ; đợt hai mới đổi IP. Xem thêm hướng dẫn trỏ tên miền về VPS.
Bước 3: Sao chép dữ liệu sang server mới
Cách thủ công
Chép file bằng rsync qua SSH. Chạy trên server mới, thay đường dẫn cho đúng với hai server:
rsync -az --info=progress2 -e ssh \
olduser@OLD_IP:/home/olduser/public_html/ \
/var/www/example.com/public_html/
Xuất database trên server cũ. Với InnoDB, --single-transaction cho bản dump nhất quán mà không khoá bảng:
mysqldump --single-transaction --quick --routines --triggers \
-u dbuser -p dbname | gzip > dbname.sql.gz
Nhập vào server mới sau khi đã tạo database và user:
gunzip < dbname.sql.gz | mysql -u dbuser -p dbname
Sau đó kiểm tra quyền sở hữu file (nếu chạy rsync bằng root, file có thể mang uid không đúng với user website trên server mới) và cập nhật thông tin kết nối database trong wp-config.php hoặc .env nếu tên database, user hay mật khẩu thay đổi.
Với ZoPanel
Nếu server cũ dùng cPanel hoặc DirectAdmin, mở Chuyển đến trong menu quản trị. Bạn tải lên bản backup đầy đủ của tài khoản (tối đa 50 GB) hoặc đưa đường dẫn tải về, xem kết quả phân tích, xử lý xung đột tên rồi bấm Bắt đầu nhập. Website, database, hộp thư, forwarder và cron được dựng lại; với bản backup cPanel còn có chứng chỉ SSL, và vùng DNS nếu server mới đã cài máy chủ DNS. Mật khẩu database được giữ khi định dạng hash cho phép, nếu không thì mật khẩu mới được ghi thẳng vào file cấu hình của ứng dụng.
Cần chuyển cả server, dùng Chuyển đến → Chuyển cả server: nhập địa chỉ và SSH root của server cũ, chọn các tài khoản, ZoPanel tự tạo backup bên đó, tải về, nhập và dọn file tạm từng tài khoản một. Giữa hai server ZoPanel, tính năng Chuyển website (qua quản lý nhiều server) giữ nguyên tên database, user và mật khẩu, nên wp-config.php không cần sửa. Trong mọi trường hợp, server cũ không bị thay đổi gì. Chi tiết từng mục được và không được chuyển nằm ở tài liệu chuyển đổi; nếu bạn đi từ cPanel, xem thêm bài chuyển hosting cPanel sang VPS.
Bước 4: Thử website trên server mới khi DNS chưa đổi
Đây là bước tạo ra sự khác biệt giữa "hy vọng nó chạy" và "biết chắc nó chạy". Bạn bắt máy tính của mình phân giải tên miền về IP mới, trong khi cả thế giới vẫn vào server cũ.
Trên Linux và macOS, thêm một dòng vào /etc/hosts (trên Windows là C:\Windows\System32\drivers\etc\hosts, mở Notepad bằng quyền Administrator):
203.0.113.10 example.com www.example.com
Trong đó 203.0.113.10 là IP server mới. Mở trình duyệt ở cửa sổ ẩn danh và đi qua các luồng quan trọng: trang chủ, đăng nhập quản trị, tìm kiếm, form liên hệ, giỏ hàng, thanh toán thử. Xong việc nhớ xoá dòng này đi, nếu không chính bạn sẽ bị kẹt ở server mới hoặc cũ mà không biết.
Nếu chỉ cần kiểm tra nhanh từ dòng lệnh, curl --resolve làm điều tương tự mà không đụng vào file hosts:
curl -sI --resolve example.com:80:203.0.113.10 http://example.com/
Mã 200 (hoặc 301 về HTTPS) là dấu hiệu tốt. Mã 500 nghĩa là cần xem log lỗi PHP trước khi đi tiếp.
Bước 5: Chuẩn bị SSL trước khi đổi DNS
Let's Encrypt xác minh quyền sở hữu tên miền qua HTTP (thử thách HTTP-01) hoặc qua DNS (DNS-01), như mô tả trong tài liệu chính thức về các loại thử thách. Với HTTP-01, tên miền phải trỏ về server mới thì mới xin được chứng chỉ, nên sẽ có một khoảng ngắn sau khi đổi DNS mà server mới chưa có chứng chỉ hợp lệ. Có hai cách lấp khoảng trống này:
- Mang chứng chỉ cũ sang. Chứng chỉ đang dùng trên server cũ (kèm private key) vẫn hợp lệ cho tên miền ở bất kỳ server nào cho tới ngày hết hạn. Cài nó lên server mới, đổi DNS, rồi xin chứng chỉ mới sau.
- Dùng DNS-01, nếu bạn kiểm soát vùng DNS và công cụ cấp chứng chỉ hỗ trợ nhà cung cấp DNS của bạn.
Trên ZoPanel, khi nhập từ bản backup cPanel, chứng chỉ SSL được cài sẵn dưới dạng chứng chỉ riêng. Với các trường hợp khác, dán chứng chỉ và key vào thẻ Chứng chỉ riêng trong tab SSL của website. Sau khi DNS đã trỏ hẳn về server mới, bấm Cấp chứng chỉ để chuyển sang Let's Encrypt và kiểm tra lại rằng tự động gia hạn đang bật. Nếu website tạo mới với SSL miễn phí (Let's Encrypt), ZoPanel kiểm tra DNS mỗi giờ và tự cấp chứng chỉ ngay khi tên miền chỉ còn phân giải về server này. Xem tài liệu SSL.
Bước 6: Đóng băng ghi và đồng bộ lần cuối
Website tĩnh hay blog ít cập nhật thì bỏ qua được bước này. Website có dữ liệu ghi liên tục (WooCommerce, diễn đàn, hệ thống đặt lịch) thì không: mọi đơn hàng phát sinh trên server cũ sau lúc bạn dump database sẽ không có mặt trên server mới.
Cách làm thực tế:
- Chọn giờ ít khách nhất (xem biểu đồ truy cập).
- Bật chế độ bảo trì hoặc tạm khoá chức năng ghi (tắt đặt hàng, tắt đăng ký) trên server cũ. Với website nhỏ, thời gian này thường chỉ vài phút.
- Dump database lần cuối và nhập lại vào server mới. Chạy lại
rsyncđể lấy các file tải lên mới (ảnh sản phẩm, tài liệu). - Đổi DNS ngay sau đó (bước 7) và mở lại chức năng ghi trên server mới.
Nói thẳng: với website có dữ liệu ghi, "không gián đoạn" thực chất là "không có lỗi, chỉ vài phút tạm dừng nhận đơn". Muốn tuyệt đối không dừng, bạn cần cấu hình nâng cao như cho server cũ làm reverse proxy chuyển mọi request sang server mới ngay sau khi đồng bộ, để tất cả lượt ghi đi vào một database duy nhất. Cách này hiệu quả nhưng phức tạp hơn nhiều, chỉ đáng làm với cửa hàng doanh thu lớn.
Bước 7: Đổi DNS và theo dõi
- Sửa bản ghi A (và AAAA nếu server mới có IPv6; nếu không có, xoá AAAA cũ) về IP mới.
- Nếu server mới nhận email, đổi MX và cập nhật SPF. Trong giai đoạn chuyển tiếp, để SPF cho phép cả hai IP, ví dụ
v=spf1 ip4:OLD_IP ip4:NEW_IP mx ~all, rồi bỏ IP cũ sau vài ngày. - Kiểm tra qua nhiều resolver:
dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8
- Theo dõi access log trên cả hai server. Lượt truy cập vào server cũ giảm dần về gần 0 sau vài lần TTL. Một số resolver giữ bản ghi lâu hơn TTL, nên giữ server cũ chạy ít nhất 48 đến 72 giờ trước khi huỷ dịch vụ.
- Về email: thư gửi tới trong lúc DNS đang chuyển có thể vẫn rơi vào server cũ. Sau khi MX đã ổn định, đồng bộ hộp thư từ server cũ sang server mới bằng công cụ như imapsync, công cụ chỉ chép những thư còn thiếu.
- Khi mọi thứ đã ổn, nâng TTL trở lại (ví dụ 3600 giây) để giảm tải truy vấn DNS.
Những lỗi thường gặp cần tránh
- Huỷ server cũ ngay khi website mới chạy. Hãy chờ vài ngày và giữ một bản sao lưu cuối cùng.
- Quên cron, hoặc để cron chạy trên cả hai server. Một bên làm tác vụ âm thầm dừng, bên kia khiến khách nhận email và đơn bị xử lý hai lần. Tắt cron ở server cũ ngay khi đổi DNS.
- Đổi cùng lúc quá nhiều thứ (server, phiên bản PHP, theme, nameserver). Chuyển trước, nâng cấp sau.
Kết luận
Chuyển hosting không gián đoạn không cần phép màu, chỉ cần đúng thứ tự: hạ TTL sớm, chép dữ liệu, kiểm thử bằng file hosts, chuẩn bị SSL, đồng bộ lần cuối, đổi DNS và giữ server cũ thêm vài ngày. Phần lớn sự cố đều đến từ việc bỏ qua một trong các bước đó.
Nếu server mới của bạn chạy ZoPanel, việc nhập tài khoản cPanel hay DirectAdmin, kể cả chuyển cả server, đã được tự động hoá; gói Free cho 3 tài khoản hosting, 10 website và 10 database, không giới hạn thời gian, đủ để thử chuyển vài website thật trước khi quyết định. Xem bảng giá và tài liệu chuyển đổi để bắt đầu.
Câu hỏi thường gặp
Chuyển hosting mất bao lâu thì DNS cập nhật xong?
Nếu bạn đã hạ TTL xuống 300 giây từ trước, đa số người dùng sẽ vào server mới trong vòng vài phút sau khi đổi bản ghi A. Nếu đổi nameserver tại nhà đăng ký, hãy tính tới 48 giờ với tên miền .com, vì TTL của vùng cha nằm ngoài tầm kiểm soát của bạn.
Có thể chuyển hosting mà không đổi nameserver không?
Có, và đó thường là cách nhanh nhất. Giữ nguyên nhà cung cấp DNS hiện tại và chỉ sửa bản ghi A, AAAA và MX về IP mới. Nếu muốn chuyển cả DNS, hãy làm ở một đợt riêng, trước hoặc sau khi chuyển server.
Website WordPress có cần sửa gì sau khi chuyển không?
Nếu tên miền giữ nguyên thì không cần search-replace URL. Bạn chỉ cần kiểm tra thông tin database trong wp-config.php, quyền file, phiên bản PHP và cron. Khi chuyển giữa hai server ZoPanel, tên database, user và mật khẩu được giữ nguyên nên wp-config.php không phải sửa.
Email có bị mất khi chuyển hosting không?
Không nếu bạn làm đúng thứ tự: chép hộp thư sang trước, hạ TTL của MX, đổi MX, rồi đồng bộ lại các thư đến server cũ trong lúc chuyển. Giữ hộp thư trên server cũ vài ngày để đối chiếu.
Đọc tiếp

Chuyển toàn bộ server hosting cPanel sang server mới: quy trình
Quy trình chuyển toàn bộ server hosting cPanel hoặc DirectAdmin sang server mới: kiểm kê, hạ TTL, chuyển theo đợt, đổi DNS, xử lý email và dữ liệu phát sinh.

Chuyển từ DirectAdmin sang VPS mới mà không mất website, email
Hướng dẫn chuyển từ DirectAdmin sang VPS mới: tạo bản backup, những gì mang theo được, nhập bằng panel hoặc thủ công, đổi DNS và kiểm tra để không mất email.

Dùng Cloudflare cho VPS: cấu hình SSL, DNS, IP thật đúng cách
Hướng dẫn dùng Cloudflare cho VPS - chế độ SSL Full (strict), bản ghi nào bật proxy, lấy IP thật của khách, tránh lỗi chuyển hướng vô hạn và lộ IP gốc.