Top các giải pháp thay thế DigitalOcean cho lập trình viên

Những thay đổi thực tế từ các giải pháp thay thế DigitalOcean

Hầu hết các giải pháp thay thế DigitalOcean chỉ thay đổi hóa đơn, không thay đổi máy chủ. Dù chọn nhà cung cấp nào, bạn vẫn nhận được một máy ảo Linux với IP công cộng, ổ đĩa virtio và quyền root; kernel của bạn không quan tâm logo nào hiển thị trên bảng điều khiển. Các khác biệt quyết định lựa chọn là giá trên mỗi GB RAM, dung lượng truyền tải dữ liệu (transfer allowance) đi kèm và chi phí cho mỗi byte vượt mức, bản chất thực sự của ổ đĩa, và mức độ quản lý các tầng phía trên hệ điều hành mà nhà cung cấp hỗ trợ cho bạn.

Hướng dẫn này so sánh dựa trên các tiêu chí đó, vì một lập trình viên có thể kiểm tra từng tiêu chí từ terminal hoặc từ bảng giá công khai. Tài liệu này cũng nêu rõ các trường hợp mà DigitalOcean là lựa chọn phù hợp, vì một bài so sánh không thừa nhận bất kỳ ưu điểm nào của đối thủ chỉ là quảng cáo.

Mọi mức giá dưới đây là giá niêm yết công khai, được kiểm tra vào ngày 5 tháng 8 năm 2026. Giá cả luôn biến động và đã có nhiều nhà cung cấp trong danh sách này thay đổi giá trong năm 2026. Cấu trúc giá thay đổi chậm hơn nhiều, vì vậy hãy đọc kỹ các tỷ lệ và mô hình thanh toán trước, sau đó xác nhận lại con số hiện tại trên trang chủ của nhà cung cấp trước khi bạn quyết định sử dụng.

Giá trên mỗi GB RAM là chỉ số cần so sánh

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

Trong cùng một nhà cung cấp, giá trên mỗi GB RAM gần như không thay đổi. DigitalOcean tính phí $6.00 cho mỗi GB trên gói 1 GB và cũng là $6.00 cho mỗi GB trên gói 4 GB, với giá niêm yết là $24.00 mỗi tháng. Việc chọn gói lớn hơn tại cùng một nhà cung cấp không giúp bạn được giảm giá, vì vậy quy mô gói không phải là yếu tố quyết định. Nhà cung cấp mới là yếu tố đó.

Akamai, đơn vị hiện đang bán các dịch vụ trước đây là Linode, định giá các gói shared 2 GB và 4 GB của họ ở mức $12 và $24, bằng đúng số tiền với DigitalOcean. Gói khởi điểm của họ rẻ hơn với mức $5.00. Việc hai công ty có mức giá khớp nhau hoàn toàn là một tín hiệu đáng chú ý: phân khúc đó được định giá dựa trên đối thủ cạnh tranh chứ không phải dựa trên phần cứng, và nó sẽ tiếp tục bám sát đối thủ đó.

Khoảng cách giá xuất hiện với các nhà cung cấp tự xây dựng trung tâm dữ liệu và bán bằng đồng euro. Một gói Hetzner CX23 cung cấp cho bạn 4 GB RAM với giá khoảng $6.49 mỗi tháng, tương đương $1.62 cho mỗi GB, gần bằng một phần tư mức giá của DigitalOcean. Con số bằng đô la đó được quy đổi từ giá niêm yết bằng euro, nên nó sẽ biến động theo tỷ giá hối đoái. Hetzner cũng đã tăng giá cloud trong năm 2026, vì vậy các bài viết so sánh cũ thường trích dẫn những con số không còn tồn tại.

Giá trên mỗi GB RAM không cho biết gì về CPU bạn nhận được. vCPU shared nghĩa là hypervisor sẽ lập lịch cho core của bạn cùng với các khách hàng khác, và bài kiểm tra trung thực nhất được thực hiện trên chính máy chủ bạn đã thuê:

vmstat 1 10

Hãy đọc cột st. Nó đếm tỷ lệ phần trăm thời gian vCPU của bạn sẵn sàng chạy nhưng hypervisor lại cấp core vật lý cho người khác. Một vài phần trăm khi chịu tải là bình thường. Một con số hai chữ số kéo dài nghĩa là máy chủ đang bị quá tải (oversubscribed), và không mức giá trên mỗi GB nào bù đắp được cho một core mà bạn không thể sử dụng. Hãy chạy lệnh này vào giờ cao điểm, vì steal time là vấn đề do hàng xóm gây ra và hàng xóm thì có lịch trình riêng. Để có cái nhìn rộng hơn về chi phí thực tế của một tháng thuê hosting sau khi đã cộng thêm lưu trữ và lưu lượng truy cập, hãy đọc chi phí VPS hàng tháng.

Chi phí thực tế của lưu lượng truyền tải đi kèm

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean bao gồm 1 TB lưu lượng truyền tải đi (outbound transfer) cho gói cơ bản và tính phí vượt mức theo GiB, tương đương khoảng $10.00 cho mỗi TB phát sinh. Akamai cung cấp cùng mức TB đó nhưng tính phí chỉ bằng một nửa, khoảng $5.00 mỗi TB. Vultr bao gồm 2 TB với mức phí vượt mức tương tự. Hetzner bao gồm 20 TB và tính phí khoảng $1.20 mỗi TB sau đó, một mức giá chênh lệch đáng kể so với các nhà cung cấp khác.

Ba chi tiết cấu trúc quan trọng hơn các con số quảng cáo. Lưu lượng truyền tải đến (inbound) là miễn phí tại cả bốn nhà cung cấp, vì vậy chỉ lưu lượng bạn gửi đi mới bị tính phí. DigitalOcean và Vultr gộp hạn mức cho tất cả các server trong tài khoản, nghĩa là một máy chủ bận rộn có thể tiêu tốn hạn mức của máy khác, và một nhóm các server nhỏ sẽ dùng chung một hạn mức lớn. Lưu lượng giữa các server qua mạng private hoặc VPC thường không bị tính phí, đó là lý do tại sao việc đặt database trên giao diện private vừa là quyết định về bảo mật, vừa là quyết định về chi phí.

Tất cả những điều này không quan trọng nếu bạn không dùng gần tới hạn mức. Một blog, một API trả về JSON hoặc một SaaS nhỏ sẽ không đạt tới 1 TB mỗi tháng. Video, thư viện ảnh, game server, mirror gói phần mềm và các đích backup từ xa thì có thể. Hãy đo lường trước khi đưa ra giả định:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m in ra lưu lượng truyền tải theo tháng, chia thành dữ liệu nhận và dữ liệu truyền đi. Chỉ cột dữ liệu truyền đi mới bị tính phí. Database bắt đầu với dữ liệu trống, vì vậy kết quả hữu ích đầu tiên sẽ có sau khi bạn cài đặt một ngày, và kết quả của một tháng đầy đủ sẽ có sau một tháng. Cho đến lúc đó, biểu đồ băng thông của chính nhà cung cấp là bản ghi duy nhất bạn có.

Hãy hỏi thêm một câu hỏi mà không bảng giá nào trả lời: khi bạn vượt quá hạn mức, nhà cung cấp sẽ tính phí bạn hay bóp băng thông (throttle) cổng mạng. Tính phí sẽ tốn tiền. Bóp băng thông sẽ làm mất người dùng, đúng vào thời điểm bạn có nhiều người dùng nhất. Bạn cần biết một đợt tăng đột biến lưu lượng sẽ dẫn đến kết quả nào.

NVMe hay SATA, và cách kiểm tra phần cứng thực tế

Bảng điều khiển ghi là NVMe. Đó là thông tin về các ổ đĩa trên máy chủ vật lý, còn máy ảo của bạn có thể không nằm trên đó. Lưu trữ cục bộ (local storage) đặt ổ đĩa ảo của bạn trên các ổ cứng bên trong cùng một máy vật lý. Lưu trữ mạng (network storage) đặt nó trên một cụm lưu trữ riêng biệt, truy cập qua mạng trung tâm dữ liệu; đây là yếu tố giúp việc thay đổi kích thước tức thì, di chuyển trực tiếp (live migration) và snapshot tại chỗ trở nên khả thi.

Bên trong máy khách (guest), cả hai loại đều trông giống hệt nhau:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA và rotational báo cáo 0 cho bất kỳ thiết bị nào mà máy chủ khai báo là không quay (non-rotational), vì vậy một volume mạng chạy trên nền NVMe sẽ báo cáo chính xác những gì mà NVMe cục bộ báo cáo. Giá trị này chỉ cho bạn biết ổ đĩa không phải là loại đĩa quay cơ học. Nó không thể cho bạn biết ổ đĩa đó nằm ở đâu. Xác nhận ổ đĩa NVMe trên Linux sẽ đi sâu vào các tên thiết bị và ý nghĩa của từng loại.

Bài kiểm tra để phân biệt chúng là độ trễ (latency) ở queue depth 1, vì một thao tác đọc nhỏ đơn lẻ không có gì để che giấu. NVMe cục bộ phản hồi từ chính khung máy đó. Một volume mạng thêm một vòng lặp (round trip) qua mạng trung tâm dữ liệu cho mỗi thao tác đọc, vì vậy mức độ trễ tối thiểu của nó cao hơn ngay cả khi thông lượng (throughput) ở queue depth sâu trông có vẻ tương đương.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

Lần chạy đầu tiên in ra một khối clat, đó là độ trễ hoàn thành. Hãy đọc dòng phần trăm thứ 99 (99th percentile) thay vì giá trị trung bình, vì giá trị trung bình che giấu các điểm khựng mà người dùng thực sự cảm nhận được. Lần chạy thứ hai in ra IOPS= trên dòng tóm tắt. Hãy chạy cả hai trên nhà cung cấp bạn đang dùng và trên một instance dùng thử của nhà cung cấp bạn đang cân nhắc, trong cùng một ngày, rồi so sánh hai con số của chính bạn. Một con số được công bố từ bất kỳ nhà cung cấp nào cũng được đo trên một máy mà bạn không thể kiểm chứng. Hãy chạy thử ba lần vào các khung giờ khác nhau, vì một máy chủ rảnh rỗi và một máy chủ bận rộn sẽ cho kết quả khác nhau trên cùng một gói dịch vụ. Benchmarking VPS đúng cách bao gồm phương pháp thực hiện, và SSD VPS thực sự nghĩa là gì giải thích các thuật ngữ marketing ẩn sau đó.

Các region: hãy đo độ trễ, đừng nhìn bản đồ

Danh sách các region chỉ là marketing cho đến khi bạn thực sự đo lường chúng. Điều người dùng cảm nhận được là thời gian khứ hồi (round trip) từ mạng của họ đến máy chủ của bạn, và điều đó phụ thuộc vào lộ trình gói tin đi qua, không phải khoảng cách trên bản đồ. Một máy chủ cách 300 km nhưng nằm sau một đường truyền bị nghẽn sẽ thua xa một máy chủ cách 1.500 km trên một đường truyền thông thoáng.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr in ra từng hop kèm theo tỷ lệ mất gói và độ trễ, vì vậy một bước nhảy 60 ms giữa hai hop sẽ chỉ ra chính xác đường truyền nào đang gây vấn đề thay vì đổ lỗi cho đích đến. Hãy chạy lệnh này từ một máy nằm trong mạng mà người dùng của bạn đang sử dụng. Các lộ trình giữa các datacentre là những lộ trình tốt nhất trên Internet, và chúng làm cho mọi nhà cung cấp đều trông có vẻ tốt như nhau.

Có một điểm cấu trúc quan trọng vẫn tồn tại bất chấp mọi thay đổi về giá. Một nhà cung cấp chỉ có một region duy nhất trên lục địa của bạn đồng nghĩa với việc kế hoạch phục hồi sau thảm họa (disaster recovery) của bạn thực chất là kế hoạch chuyển sang lục địa khác, kèm theo độ trễ tương ứng. Hãy đếm số region mà bạn thực sự có thể failover sang, thay vì đếm số region được liệt kê trên trang web.

Snapshot và backup là chi phí riêng biệt

Các add-on lưu trữ là nơi một gói cước giá rẻ trở nên đắt đỏ. DigitalOcean tính phí 0,06 USD mỗi GiB mỗi tháng cho snapshot, và tính phí backup tự động dựa trên tỷ lệ phần trăm của máy chủ: 20% giá gói cho backup hàng tuần, 30% cho hàng ngày, cùng với tùy chọn tính phí theo mức sử dụng trên mỗi GiB. Cả hai mô hình đều có lý do tồn tại nhưng chúng có những điểm yếu trái ngược nhau. Giá theo tỷ lệ phần trăm tăng theo quy mô máy chủ, vì vậy một máy chủ lớn chứa ít dữ liệu sẽ bị tính phí quá cao. Giá theo GiB tăng theo lượng dữ liệu của bạn, vì vậy một máy chủ nhỏ gắn với một volume lớn sẽ bị tính phí quá cao.

Hãy hỏi chi phí khôi phục là bao nhiêu và mất bao lâu, vì giá lưu trữ backup chỉ là một nửa vấn đề. Hãy hỏi liệu việc xóa máy chủ có làm mất luôn các snapshot của nó hay không.

Sau đó, hãy giữ một bản sao mà nhà cung cấp không kiểm soát. Snapshot của nhà cung cấp nằm trong tài khoản của họ, vì vậy nếu mất quyền truy cập, thanh toán thất bại hoặc tài khoản bị tạm khóa, bạn sẽ mất cả máy chủ lẫn các bản backup cùng một lúc. backup bằng restic vào bộ nhớ bạn sở hữu chỉ tốn vài đô la cho object storage, có thể khôi phục trên bất kỳ nhà cung cấp nào, và là yếu tố giúp việc di chuyển dữ liệu có thể đảo ngược thay vì là quyết định cuối cùng.

Bạn muốn vận hành bao nhiêu phần của stack

Các nhà cung cấp nằm trên một dải lựa chọn. Ở một đầu, bạn thuê máy chủ và tự mình chạy mọi thứ. Ở đầu kia, bạn chỉ cần push một git branch và không bao giờ phải nhìn thấy server. So sánh giá trên mỗi GB RAM chỉ đúng ở đầu thứ nhất, vì ở đầu thứ hai, bạn đang mua nhân lực chứ không phải bộ nhớ, và nhân lực thì không có giá theo GB.

Hãy thành thật về vị trí của bạn trước khi so sánh bất cứ thứ gì. Một database được quản lý với giá $15.15 mỗi tháng trông có vẻ đắt đỏ so với một server $6, cho đến khi bạn tính toán chi phí cho những giờ làm việc phía sau nó: replication, failover, point in time restore, nâng cấp phiên bản minor và cảnh báo đánh thức ai đó lúc 03:00. Nếu công việc của bạn là làm những việc đó, hãy tự chạy và giữ lại phần chênh lệch. Nếu công việc của bạn là phát triển ứng dụng, thì việc mua lại dịch vụ đó là rẻ. Sự phân chia giữa managed và unmanaged quyết định cột nào trong bảng giá mà bạn nên đọc. Nếu câu trả lời thành thật là bạn muốn toàn quyền sở hữu máy chủ và ổ đĩa, đó là câu hỏi về VPS so với dedicated server thay vì là câu hỏi về nhà cung cấp.

Khi nào DigitalOcean là lựa chọn phù hợp

DigitalOcean thắng thế khi bạn mua nền tảng thay vì chỉ mua máy ảo.

• Managed databases. Managed PostgreSQL và MySQL có giá khởi điểm từ $15.15 mỗi tháng cho 1 GiB RAM và 10 GiB lưu trữ, với dung lượng lưu trữ bổ sung được tính phí theo GiB và các node dự phòng (standby nodes) được tính phí theo từng node. Việc tự xây dựng hệ thống có độ tin cậy tương đương đồng nghĩa với việc bạn phải dùng Patroni hoặc repmgr, một consensus store, một connection proxy và quy trình failover mà bạn thực sự đã diễn tập. Một đội ngũ hai người không thể duy trì hệ thống đó mà vẫn kịp phát triển tính năng.
• App Platform. Push một branch, nhận một bản build, một chứng chỉ và một dịch vụ đang chạy, không cần phải vá lỗi hệ điều hành. Phiên bản VPS giá rẻ của sản phẩm này chính là bạn, vào một ngày thứ Bảy.
• Object storage và load balancer được hỗ trợ bởi Terraform provider hoàn thiện. Một hệ thống mà bạn có thể hủy và xây dựng lại từ code có giá trị hơn là một mức giá đơn vị thấp hơn.
• Công ty đứng sau sản phẩm. Các gói hỗ trợ được công bố, trang trạng thái có lưu trữ lịch sử và một tổ chức sẵn sàng trả lời bảng câu hỏi bảo mật của khách hàng. Nếu bạn kinh doanh dịch vụ hosting, điều đó đáng giá hơn vài đô la mỗi GB.

DigitalOcean trở nên đắt đỏ khi bạn dùng máy ảo thuần túy, với số lượng lớn và lưu lượng outbound thực tế. Đó chính xác là trường hợp mà các giải pháp thay thế giải quyết được, và đó cũng là phần lớn những gì một lập trình viên tự host (self-hosting) thường mua.

Di chuyển sang nhà cung cấp mới mà không gây downtime

Downtime trong quá trình di chuyển xuất phát từ một nguyên nhân duy nhất: lưu lượng truy cập vẫn đổ về IP cũ sau khi dữ liệu đã được chuyển sang máy chủ mới. Mọi bước dưới đây đều nhằm mục đích thu hẹp khoảng thời gian này và làm cho nó có thể dự đoán được.

Hãy bắt đầu với DNS, ít nhất 48 giờ trước khi di chuyển. Các trình phân giải (resolver) cache bản ghi A của bạn theo thời gian TTL (time to live), vì vậy một bản ghi có TTL 24 giờ sẽ tiếp tục gửi người dùng đến máy chủ cũ trong tối đa một ngày sau khi bạn thay đổi. Việc giảm TTL ngay tại thời điểm chuyển đổi không có tác dụng, vì các trình phân giải đã lưu giá trị cũ kèm theo thời hạn cũ rồi. Hãy giảm TTL trước, đợi giá trị cũ hết hạn, sau đó mới di chuyển.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

Lệnh đầu tiên in ra TTL hiện tại ở cột thứ hai của kết quả. Hãy đặt nó thành 300 tại nhà cung cấp DNS của bạn, sau đó đợi lâu hơn khoảng thời gian bạn vừa thay thế.

Sau đó thực hiện theo thứ tự này.

1. Cấp phát máy chủ mới và bảo mật nó trước khi đưa bất cứ thứ gì lên đó. Mười phút đầu tiên trên một VPS mới đề cập đến phần mà mọi người thường bỏ qua khi đang vội.
2. Cài đặt stack ứng dụng và chạy lần sao chép dữ liệu đầu tiên bằng rsync trong khi máy chủ cũ vẫn phục vụ bình thường.
3. Cấp chứng chỉ TLS trên máy chủ mới ngay bây giờ, sử dụng DNS-01 challenge, vì HTTP-01 challenge xác thực dựa trên IP mà DNS hiện đang trỏ tới, vốn vẫn là máy chủ cũ. DNS-01 challenge loại bỏ hoàn toàn vấn đề thứ tự này.
4. Kiểm tra máy chủ mới trước khi thay đổi công khai bằng cách ghi đè DNS trên laptop của chính bạn. Thêm 203.0.113.20 example.com vào /etc/hosts, duyệt trang web thực tế, sau đó xóa dòng đó đi. Không người dùng nào bị ảnh hưởng bởi bài kiểm tra này.
5. Giải quyết vấn đề dung lượng cơ sở dữ liệu. Với dung lượng dưới vài GB, việc dump và restore nằm gọn trong khoảng thời gian đóng băng ghi (write freeze). Nếu lớn hơn, hãy thiết lập replication từ cơ sở dữ liệu cũ sang cơ sở dữ liệu mới trước vài ngày và để nó đồng bộ, như vậy thời gian đóng băng chỉ còn là lúc chuyển đổi (promotion).
6. Đóng băng các thao tác ghi. Đưa ứng dụng vào chế độ bảo trì hoặc chỉ đọc (read-only). Đây là phần duy nhất người dùng có thể thấy, và nó chỉ nên kéo dài vài phút.
7. Chạy lần đồng bộ cuối cùng: chạy lại rsync như cũ, sau đó là đồng bộ cơ sở dữ liệu cuối cùng.
8. Thay đổi các bản ghi A và AAAA sang IP mới. Với TTL 300 giây, hầu hết các trình phân giải sẽ cập nhật trong khoảng năm phút.
9. Để máy chủ cũ chạy và có thể truy cập được trong ít nhất một ngày, vì một số trình phân giải bỏ qua các TTL ngắn. Nếu ứng dụng cũ vẫn có thể ghi, các yêu cầu đến muộn sẽ ghi vào sai cơ sở dữ liệu, vì vậy hãy trỏ máy chủ cũ vào cơ sở dữ liệu mới hoặc trả về trang bảo trì từ đó.
10. Theo dõi tỷ lệ lỗi của máy chủ mới trong một ngày, tăng TTL trở lại giá trị bình thường và hủy máy chủ cũ sau một tuần thay vì ngay trong tối hôm đó.

Việc sao chép bao gồm hai lệnh, mỗi lệnh chạy hai lần. Đồng bộ file:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a bảo toàn quyền sở hữu, quyền truy cập và dấu thời gian, -H giữ các hard link, -AX giữ các ACL và thuộc tính mở rộng, và --numeric-ids ngăn rsync ánh xạ lại ID người dùng thông qua các tên khác nhau giữa hai máy. Hãy chạy lệnh này trước vài ngày, sau đó chạy lại trong lúc đóng băng, khi đó nó chỉ chuyển những gì đã thay đổi.

Đối với PostgreSQL đủ nhỏ để dump:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

Đối với MySQL hoặc MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction thực hiện dump trong một transaction trên các bảng InnoDB, vì vậy kết quả nhất quán và ứng dụng vẫn có thể ghi trong khi lệnh chạy. Nếu không có flag này, mysqldump sẽ khóa các bảng, nghĩa là thời gian đóng băng ghi của bạn bắt đầu sớm hơn dự kiến và bạn không thể kiểm soát thời điểm đó.

Có hai thứ sẽ gặp lỗi bên ngoài máy chủ của bạn. Một địa chỉ IP mới không có uy tín email, vì vậy thư gửi trực tiếp từ máy chủ mới sẽ bị lọc là spam: hãy gửi qua một relay đã có uy tín. Và bất kỳ đối tác nào cho phép IP gửi đi của bạn (allowlist), chẳng hạn như cổng thanh toán hoặc firewall của khách hàng, đều phải được cập nhật trước khi chuyển đổi, nếu không các kết nối đó sẽ bắt đầu lỗi ngay khi lưu lượng chuyển hướng.

Những điều cần kiểm tra trước khi cam kết

• Giá có phải là giá khuyến mãi không và giá gia hạn là bao nhiêu. Mức giảm giá cho kỳ đầu tiên mà tăng gấp đôi khi gia hạn thực chất là một khoản chi phí, chỉ là bị trì hoãn mà thôi.
• Thời hạn có được trả trước không. Các gói trả trước nhiều năm, cách mà SSD Nodes đang bán, giúp đổi lấy mức giá thấp hơn trên mỗi GB RAM bằng cách trả tiền trước. Đổi lại, bạn không thể rời đi vào tháng sau, vì vậy hãy cân nhắc thời hạn dựa trên mức độ chắc chắn của bạn.
• Chi phí snapshot mỗi tháng là bao nhiêu, và chi phí khôi phục tính bằng tiền và thời gian (phút) là bao nhiêu.
• Lưu lượng vượt mức (overage) được tính phí hay bị bóp băng thông.
• IPv6 được định tuyến đúng cách hay chỉ là một địa chỉ đơn lẻ được gắn thêm vào.
• Có API với Terraform provider được duy trì hay không, nếu bạn dự định rebuild từ code thay vì làm thủ công.
• Cách liên hệ hỗ trợ, và thời gian phản hồi công bố cho trường hợp server bị down thay vì cho các câu hỏi bán hàng.

Hãy chọn dựa trên yếu tố chiếm tỷ trọng lớn nhất trong hóa đơn của bạn. Nếu đó là bộ nhớ, giá trên mỗi GB RAM sẽ quyết định. Nếu đó là lưu lượng outbound, dung lượng transfer đi kèm sẽ quyết định. Nếu đó là thời gian của bạn, nền tảng managed sẽ quyết định, và nền tảng của DigitalOcean là mạnh nhất trong bốn cái được so sánh ở đây.

FAQ

Hetzner có luôn rẻ hơn DigitalOcean không?

Đối với một máy ảo cơ bản, giá trên mỗi GB RAM rẻ hơn nhiều: khoảng $1.62 so với $6.00 trên các gói shared entry-level tính đến ngày 5 tháng 8 năm 2026. Sự so sánh sẽ thay đổi khi tính đến các dịch vụ được quản lý (managed services). Hetzner chỉ bán server và hạ tầng mạng, vì vậy bạn phải tự triển khai database được quản lý hoặc nền tảng push-to-deploy, hoặc sử dụng dịch vụ từ bên thứ ba, và những công việc đó đều tốn chi phí nhân sự. Hetzner cũng đã tăng giá cloud trong năm 2026, vì vậy hãy kiểm tra con số euro hiện tại thay vì tin vào các bài viết cũ.

Tôi nên chọn giải pháp thay thế DigitalOcean nào nếu cần managed database?

Vultr và Akamai đều cung cấp managed database, đây là những lựa chọn thay thế gần nhất nếu managed database là lý do chính khiến bạn dùng DigitalOcean. Các nhà cung cấp giá rẻ tại châu Âu thường không bán dịch vụ này, đồng nghĩa với việc bạn phải tự vận hành PostgreSQL hoặc MySQL, bao gồm cả việc thiết lập replication và failover đã qua kiểm thử. Đó là một công việc thực thụ. Hãy cân nhắc chi phí đó so với mức $15.15 mỗi tháng cho một instance 1 GiB được quản lý trước khi quyết định rằng server rẻ hơn đã giúp bạn tiết kiệm được gì.

Làm thế nào để chuyển một trang web đang hoạt động sang nhà cung cấp mới mà không bị downtime?

Hãy giảm TTL của DNS xuống 300 giây ít nhất 48 giờ trước khi chuyển, vì các trình phân giải (resolver) vẫn tiếp tục phục vụ IP cũ theo thời gian TTL trước đó. Hãy xây dựng và kiểm thử host mới trong khi host cũ vẫn đang phục vụ lưu lượng, sử dụng /etc/hosts để ghi đè trên máy của chính bạn để không ai khác nhìn thấy. Sau đó, tạm dừng việc ghi dữ liệu trong vài phút, chạy rsync delta cuối cùng và đồng bộ database lần cuối, chuyển đổi các bản ghi A và AAAA, rồi giữ server cũ chạy thêm một tuần phòng trường hợp có trình phân giải nào bỏ qua TTL ngắn.

VPS rẻ hơn có nghĩa là ổ cứng chậm hơn không?

Không hẳn. Điều quan trọng là ổ đĩa ảo của bạn nằm cục bộ trên host hay trên một cụm lưu trữ mạng, và bảng điều khiển hiếm khi ghi rõ điều này. lsblk -o NAME,ROTA báo cáo 0 cho cả hai, vì cả hai đều là ổ cứng không quay. Hãy đo lường bằng cách khác: chạy fio với --iodepth=1 --bs=4k --direct=1 và đọc độ trễ hoàn thành ở phân vị thứ 99. Một volume mạng sẽ thêm một vòng lặp mạng trung tâm dữ liệu vào mỗi lần đọc, vì vậy mức độ trễ tối thiểu của nó cao hơn so với NVMe cục bộ ngay cả khi throughput ở hàng đợi sâu trông có vẻ tương đương.

Email của tôi có còn được gửi đi từ server mới không?

Thường là không, lúc mới bắt đầu. Một địa chỉ IP mới không có lịch sử gửi mail, vì vậy các bên nhận sẽ coi mail từ IP đó là đáng ngờ và nó sẽ rơi vào mục spam hoặc bị từ chối thẳng. Các bản ghi SPF và DKIM cũng đang trỏ về host cũ cho đến khi bạn cập nhật chúng. Hãy gửi mail ứng dụng thông qua một relay hoặc một dịch vụ email đã có uy tín, và cập nhật các bản ghi DNS cho mail trước khi chuyển đổi thay vì làm sau đó.