[Trang chủ](https://servhidden.com/vi) /
[Hướng Dẫn Privacy Hosting](https://servhidden.com/vi/guides) /
Chiến lược sao lưu VPS: mã hóa, ngoài máy chủ, khôi phục được






Vận hành


# Sao lưu VPS thực sự khôi phục được



Hosting không KYC gỡ bỏ lưới an toàn cùng với thủ tục giấy tờ: không lưu giữ bản sao lưu, dữ liệu bị hủy trong vòng 24 giờ sau khi chấm dứt dịch vụ, và không có con đường hỗ trợ nào kết thúc bằng một bản sao được khôi phục. Đây là kế hoạch thực chiến: sao lưu gì, đặt ở đâu, làm sao ngăn kẻ tấn công xóa nó, và làm sao chứng minh nó khôi phục được.


[Đọc hướng dẫn](#guide-body)
[FAQ](#guide-faq)






## Trên trang này




- [Hướng dẫn](#guide-body)

- [FAQ](#guide-faq)

- [Hướng dẫn liên quan](#guide-related)

- [Trang được đề xuất](#guide-cta)






Không KYC
Chỉ nhận Crypto
Không lưu nhật ký
Bỏ qua DMCA
Toàn quyền Root
NVMe SSD





36 phút đọc
Cập nhật Aug 2026

Trên trang này

[01Điều gì thực sự phá hủy máy chủ](#Điều-gì-thực-sự-phá-hủy-máy-chủ)
[02Snapshot không phải là bản sao lưu, và nhà cung cấp của bạn cũng vậy](#snapshot-không-phải-là-bản-sao-lưu-và-nhà-cung-cấp-của-bạn-c)
[03Quy tắc 3-2-1, viết lại cho những người chưa từng xuất trình giấy tờ tùy thân](#quy-tắc-3-2-1-viết-lại-cho-những-người-chưa-từng-xuất-trình-)
[04Push, pull, và sai lầm khiến một đêm tồi tệ nuốt luôn cả hai bản sao](#push-pull-và-sai-lầm-khiến-một-đêm-tồi-tệ-nuốt-luôn-cả-hai-b)
[05Mã hóa tại nguồn, rồi mới quyết định ai giữ khóa](#mã-hóa-tại-nguồn-rồi-mới-quyết-định-ai-giữ-khóa)
[06Chọn công cụ, gói gọn trong một bảng](#chọn-công-cụ-gói-gọn-trong-một-bảng)
[07Bất cứ thứ gì đang chạy đều không phải là một file](#bất-cứ-thứ-gì-đang-chạy-đều-không-phải-là-một-file)
[08Cần sao lưu những gì, và những phần mà ai cũng quên](#cần-sao-lưu-những-gì-và-những-phần-mà-ai-cũng-quên)
[09Một bản khôi phục chưa được kiểm chứng chỉ là lời đồn](#một-bản-khôi-phục-chưa-được-kiểm-chứng-chỉ-là-lời-đồn)
[10Tự động hóa để nó cứ tiếp tục diễn ra](#tự-động-hóa-để-nó-cứ-tiếp-tục-diễn-ra)
[11Bản tóm tắt](#bản-tóm-tắt)
[FAQCâu hỏi thường gặp](#guide-faq)
[→Trang được đề xuất](#guide-cta)







Một chiến lược sao lưu không bao giờ được kiểm chứng vào cái đêm máy chủ chết. Nó được kiểm chứng từ nhiều tuần trước đó, qua ba quyết định âm thầm mà không ai ghi lại: bản sao sẽ nằm ở đâu, ai được phép xóa nó, và đã từng có ai thực sự khôi phục thử một bản chưa.

Dịch vụ hosting không bao giờ hỏi danh tính của bạn thì cũng đánh đổi lại một điều gì đó, và đây là chỗ để nói thẳng ra. Không có quản lý tài khoản để gọi, không có ticket nào hồi sinh một ổ đĩa đã bị xóa sạch, và [chính sách lưu trữ dữ liệu của chúng tôi](https://servhidden.com/vi/privacy) nói rõ lý do: dữ liệu máy chủ bị hủy trong vòng 24 giờ sau khi chấm dứt dịch vụ, ổ đĩa được xóa bằng phương pháp mã hóa thay vì định dạng lại, và **không có bản sao lưu nào được lưu giữ**. Đó chính là đặc tính khiến nền tảng này đáng để dùng, nhìn từ phía ngược lại. Bất cứ thứ gì bạn muốn giữ lại sau một đêm tồi tệ đều phải đã ở nơi khác từ trước, và chính bạn là người đặt nó ở đó.

## Điều gì thực sự phá hủy máy chủ

Hầu như không ai mất máy chủ theo cách họ tưởng tượng. Hỏng hóc phần cứng thảm khốc là có thật nhưng hiếm gặp, và đó là trường hợp duy nhất mà một nhà cung cấp có năng lực đã chủ động phòng ngừa từ trước. Những mất mát thực sự xảy ra lại tẻ nhạt hơn nhiều, và mỗi kiểu lại đánh bại một loại bản sao khác nhau — đó là lý do vì sao "tôi có bản sao lưu" chưa phải là câu trả lời cho đến khi bạn nói rõ nó sống sót qua trường hợp nào trong số này.

| Điều gì xảy ra | Nó thường xảy ra như thế nào | Thứ gì cứu được bạn |
| --- | --- | --- |
| **Chính tay bạn** | Một lệnh rm -rf khi biến shell trống rỗng, một migration trỏ nhầm vào production, một lần deploy xóa mất bảng dữ liệu sai | Bất kỳ bản sao nào nằm ngoài máy chủ từ *trước* khi xảy ra sai sót — nghĩa là thời gian lưu giữ phải dài hơn thời gian bạn cần để nhận ra vấn đề |
| **Hỏng hóc âm thầm** | Một ổ NVMe đang chết dần, một lần ghi bị cắt ngang khi khởi động lại, một cơ sở dữ liệu đã ghi các dòng hỏng suốt cả tuần | Các bản sao có phiên bản đủ sâu để chạm tới một điểm còn nguyên vẹn đã biết. Một bản sao gương duy nhất sẽ trung thành sao chép luôn cả hư hỏng |
| **Bị xâm nhập** | Một khóa bị đánh cắp, một ứng dụng chưa vá lỗi, một dependency bị đầu độc — rồi sau đó, một cách có chủ đích, đến lượt bản sao lưu của bạn | Một bản sao mà máy chủ bị xâm nhập không có quyền xóa. Không gì khác đáng tính ở đây |
| **Sự cố nhà cung cấp hoặc quốc gia** | Mất phần cứng, một hành động pháp lý tại trung tâm dữ liệu, một tài khoản hay token bạn không còn truy cập được | Một bản sao không nằm ở nhà cung cấp đó và không thuộc thẩm quyền pháp lý đó |
| **Mất khóa** | Một cụm mật khẩu bị quên, một keyfile bị xóa cùng với máy chủ mà nó bảo vệ, một header LUKS chưa ai xuất ra ngoài | **Không gì cả.** Đây là dòng duy nhất không có cột phục hồi, và nó phổ biến hơn cả hỏng hóc phần cứng |

Hãy đọc bảng này như một danh sách kiểm tra, không phải danh sách nỗi sợ. Một bản sao hằng đêm sang ổ đĩa thứ hai trên cùng máy chỉ trả lời được dòng một, không hơn. Một snapshot trên cùng bảng điều khiển trả lời được dòng một và hai. Chỉ một bản sao được giữ ở nơi máy chủ không thể chạm tới, dưới một khóa bạn vẫn còn giữ, mới trả lời được cả năm dòng.

Một điểm sao lưu chỉ cần ổ đĩa và một địa chỉ, không cần nhiều lõi CPU. Chiếc máy thứ hai rẻ nhất ở một thẩm quyền pháp lý khác đã là một điểm đích đủ năng lực — và là bản sao duy nhất sống sót qua sự cố tại nhà cung cấp đầu tiên.

## Snapshot không phải là bản sao lưu, và nhà cung cấp của bạn cũng vậy

Snapshot rất xuất sắc trong đúng việc nó làm: hoàn tác một bản nâng cấp bị lỗi, trong vài giây, không cần truyền dữ liệu đi đâu cả. Điều nó không thể làm là sống sót qua chính sự cố đã lấy đi máy chủ, bởi nó chia sẻ mọi vùng rủi ro với máy chủ đó — cùng nhà cung cấp, cùng tài khoản, cùng token thanh toán, cùng quốc gia, thường cùng cả cụm lưu trữ. Snapshot bảo vệ bạn khỏi *chính bạn*. Bản sao lưu bảo vệ bạn khỏi mọi thứ còn lại.

Sự khác biệt này quan trọng hơn ở đây so với một nhà cung cấp thông thường, vì các lưới an toàn quen thuộc đã bị gỡ bỏ một cách có chủ đích. Không ai đăng nhập vào máy chủ khách hàng, nên không ai nhận ra công việc sao lưu của bạn đã lỗi từ tháng Ba. Không có danh tính nào gắn với tài khoản, nên cũng không có con đường nào để "chứng minh bạn là ai và chúng tôi sẽ khôi phục cho bạn". Và việc chấm dứt dịch vụ là chấm dứt thật sự: một số dư hết hạn là một sự kiện mất dữ liệu, không phải một sự kiện thanh toán.

**Điều khoản 24 giờ chính là toàn bộ luận điểm.** Trên nền tảng này, dữ liệu của một máy chủ đã chấm dứt bị hủy trong vòng một ngày, và ổ đĩa được xóa bằng phương pháp mã hóa thay vì định dạng lại. Không có tính năng khôi phục sau xóa, không có tầng lưu trữ lạnh âm thầm nào, không có kết quả hỗ trợ nào kết thúc bằng "chúng tôi đã tìm thấy một bản cũ hơn" — vì giữ lại một bản như vậy đồng nghĩa với việc giữ dữ liệu của bạn sau khi bạn đã yêu cầu chúng tôi không làm vậy. Lưới an toàn và quyền riêng tư là cùng một sự đánh đổi, được thực hiện một lần duy nhất.

## Quy tắc 3-2-1, viết lại cho những người chưa từng xuất trình giấy tờ tùy thân

Quy tắc kinh điển nói: ba bản sao, trên hai loại phương tiện lưu trữ, một trong số đó đặt ở nơi khác. Nó được viết ra cho thời đại của băng từ và đĩa quay, và điều khoản về "phương tiện" đã âm thầm mất hết ý nghĩa: ổ đĩa production của bạn là NVMe, ổ đĩa của điểm sao lưu cũng là NVMe, và gọi đó là "hai loại phương tiện" chỉ là câu chuyện bạn tự kể cho mình nghe. Điều khoản đáng giữ lại là điều khoản về khoảng cách, và với hạ tầng offshore, khoảng cách không được đo bằng kilômét.

Hãy viết lại thành **ba bản sao, hai nhà cung cấp, hai thẩm quyền pháp lý**. Những sự cố xóa sổ cả hai bản sao cùng lúc gần như không bao giờ là sự cố vật lý — đó là một tài khoản bạn mất quyền truy cập, một nhà cung cấp gặp một tuần tồi tệ, hoặc một văn bản pháp lý có hiệu lực ở một quốc gia nhưng không với tới quốc gia khác. Hai máy chủ trong cùng một rack chỉ là một bản sao với thêm vài bước; hai máy chủ dưới cùng một chế độ pháp lý cũng khá hơn không đáng kể. [Hướng dẫn chọn thẩm quyền pháp lý](https://servhidden.com/vi/guides/choosing-an-offshore-jurisdiction) của chúng tôi trình bày cách chọn một thẩm quyền thứ hai không đơn thuần lặp lại rủi ro của thẩm quyền đầu tiên.

Trong thực tế, điều này khá rẻ. Một điểm sao lưu không cần nhiều lõi CPU, và cũng gần như không cần mạng — nó chỉ cần ổ đĩa và một địa chỉ. Gói [VPS](https://servhidden.com/vi/vps) nhỏ nhất tại một trong [bảy địa điểm](https://servhidden.com/vi/locations) khác của chúng tôi đã là một điểm đích đủ năng lực cho restic hay Borg, và với các kho lưu trữ tính bằng terabyte, một [máy chủ chuyên dụng](https://servhidden.com/vi/dedicated) với ổ đĩa thật có chi phí trên mỗi terabyte thấp hơn bất kỳ dịch vụ object storage nào. Khi dữ liệu thực sự lớn và hiếm khi được đọc lại, bài toán kinh tế nghiêng hẳn về phía bare metal.

Một điều mà mọi người thường làm đúng ở production nhưng lại làm sai ở điểm sao lưu: hãy thanh toán cho nó theo cùng một cách. Một máy chủ thứ hai được mua bằng thẻ mang tên thật của bạn sẽ âm thầm gắn lại chính danh tính mà bạn đã tốn công gỡ bỏ khỏi máy chủ đầu tiên, và giờ nó lại đang giữ một bản sao đầy đủ của mọi thứ trên đó. Nếu máy chủ production được thanh toán [bằng Monero](https://servhidden.com/vi/guides/how-to-pay-for-hosting-with-monero), máy chủ sao lưu cũng xứng đáng được đối xử như vậy.

Bản sao thứ ba là bản mà hầu hết mọi người bỏ qua, và đây là bản duy nhất miễn nhiễm với mọi sự cố từ xa cùng lúc: một ổ đĩa bạn cầm trong tay, cập nhật thỉnh thoảng, giữ ngoại tuyến. Mỗi tháng một lần là đủ với hầu hết mọi người. Nó chỉ tốn công sức bằng một tách cà phê, và đó là bản sao sống sót qua những kịch bản mà hai bản kia cùng gặp phải.

## Push, pull, và sai lầm khiến một đêm tồi tệ nuốt luôn cả hai bản sao

Đây là cách sắp xếp mà hầu như ai cũng dựng lên đầu tiên. Một tác vụ trên máy chủ production chạy mỗi đêm, giữ một khóa hoặc token cho điểm sao lưu, kết nối tới đó, rồi đẩy dữ liệu sang (push). Nó hoạt động, nó đơn giản, và nó có một đặc tính chỉ lộ ra vào ngày tồi tệ nhất trong đời máy chủ: **ai kiểm soát được máy production thì cũng kiểm soát luôn cả bản sao lưu.**

Đó không phải là một giả định. Xóa hoặc mã hóa bản sao lưu của nạn nhân trước khi lộ diện là thông lệ chuẩn của bất kỳ ai làm việc này một cách chuyên nghiệp — thông tin xác thực nằm sẵn trong một cron job hay một file môi trường, và tìm ra chúng chỉ mất khoảng một phút. Một bản sao mà kẻ tấn công có thể xóa thì không phải là bản sao thứ hai. Đó chỉ là bản gương của bản đầu tiên, có thêm một chút độ trễ.

Có hai cách khắc phục gọn gàng, và chúng kết hợp tốt với [các bước gia cố cơ bản](https://servhidden.com/vi/guides/first-hour-vps-hardening-checklist) mà lẽ ra bạn đã làm từ trước.

- **Điểm đích chỉ ghi thêm (append-only).** Cả hai công cụ chính đều hỗ trợ một chế độ mà client có thể thêm dữ liệu nhưng không thể xóa nó. Borg làm điều này bằng cách ghim khóa SSH trên điểm đích với borg serve --append-only; restic làm điều tương tự với một REST server khởi động bằng --append-only. Máy chủ production ghi dữ liệu mỗi đêm và về cấu trúc là không thể phá hủy lịch sử. Việc dọn bớt các snapshot cũ khi đó diễn ra ở phía điểm đích, trong một phiên mà máy production không thể khởi tạo.

- **Pull thay vì push.** Đảo ngược hướng kết nối: máy chủ sao lưu kết nối tới production, đọc dữ liệu, rồi lưu lại. Production không giữ bất kỳ thông tin xác thực nào cho điểm đích, nên không có gì để đánh cắp. Hãy giới hạn khóa dùng ở phía production bằng restrict và một command= bắt buộc, để một khóa sao lưu bị đánh cắp không thể biến thành một shell.

Pull là mô hình mạnh hơn và tốn thêm chút công sức để vận hành; append-only thì gần như miễn phí nếu bạn đã dùng sẵn Borg hoặc restic. Dù chọn cách nào, nó cũng biến "kẻ tấn công đã xóa bản sao lưu của tôi" từ một kết cục thành chỉ còn là một nỗ lực bất thành. Nếu chỉ lấy một điều từ hướng dẫn này, hãy lấy phần này.

## Mã hóa tại nguồn, rồi mới quyết định ai giữ khóa

Cả hai công cụ nghiêm túc đều mã hóa ngay trên máy đang được sao lưu, trước khi bất cứ thứ gì rời khỏi mạng. Điểm đích chỉ lưu các khối dữ liệu mà nó không thể đọc hiểu — và chính điều đó khiến bản sao đặt ở nhà cung cấp khác trở nên an toàn. Máy chủ thứ hai của bạn không cần phải đáng tin cậy, hay thậm chí thân thiện; nó chỉ cần có thể kết nối tới và có ổ đĩa. Chỉ một đặc tính đó thôi cũng biến "một máy chủ ở một quốc gia tôi chẳng biết gì về nó" từ một rủi ro thành một phần hạ tầng.

Đây là một cơ chế khác với việc mã hóa chính ổ đĩa của máy chủ, và hai thứ trả lời hai câu hỏi khác nhau — hướng dẫn của chúng tôi về [mã hóa toàn bộ ổ đĩa trên VPS](https://servhidden.com/vi/guides/full-disk-encryption-on-a-vps) phân tích rõ mã hóa ổ đĩa bảo vệ được gì và không bảo vệ được gì khi máy đang chạy. Mã hóa bản sao lưu dễ làm hơn và có giá trị hơn trong hai thứ đó, vì mô hình rủi ro của nó trung thực: dữ liệu ở trạng thái nghỉ, trên phần cứng bạn không kiểm soát, và khóa thì không bao giờ đi tới đó.

Điều này dồn toàn bộ rủi ro vào việc giữ khóa. Cụm mật khẩu giờ trở thành điểm mất mát duy nhất và toàn bộ, và nó tệ hơn người ta tưởng, vì mất nó diễn ra trong im lặng — không gì bị hỏng, các tác vụ sao lưu vẫn chạy bình thường, và bạn chỉ phát hiện ra đúng vào lúc bạn cần đến chúng nhất. Ba thói quen sau khắc phục điều đó:

- Chỉ giữ cụm mật khẩu trên máy chủ dưới dạng một file mà chỉ root mới đọc được, tham chiếu bằng --password-file, để nó không bao giờ xuất hiện trong danh sách tiến trình hay lịch sử shell.

- Giữ một bản sao đọc được bằng mắt thường ở ngoài mọi máy có liên quan. Một tờ giấy trong ngăn kéo thực sự tốt hơn một trình quản lý mật khẩu đồng bộ với một tài khoản mà bạn cũng có thể mất quyền truy cập.

- Thêm một khóa thứ hai vào kho lưu trữ — bằng restic key add, hoặc một khóa Borg đã xuất ra — để một cụm mật khẩu bị quên chỉ là một sự bất tiện chứ không phải dấu chấm hết cho kho lưu trữ.

Quy tắc nằm dưới cả ba điều trên: **nếu bản sao duy nhất của khóa lại nằm trên chính máy chủ mà bản sao lưu tồn tại để thay thế, thì bạn không có bản sao lưu.** Bạn chỉ có một đống khối dữ liệu đã mã hóa và một câu chuyện kể về chúng.

## Chọn công cụ, gói gọn trong một bảng

Việc chọn công cụ ít quan trọng hơn hướng kết nối và tình trạng của khóa, đó là lý do nó xếp thứ sáu chứ không phải đầu tiên. Dù vậy, khác biệt giữa các công cụ là có thật, và chọn sai hình dạng cho công việc sẽ tạo thêm việc về sau.

| Công cụ | Mã hóa trước khi rời máy | Khử trùng lặp | Điểm đích chỉ ghi thêm | Phù hợp với |
| --- | --- | --- | --- | --- |
| **restic** | Có, toàn bộ repository | Có | Có, qua REST server của nó | Lựa chọn mặc định. Nói được SFTP, object storage và server riêng của nó, nên điểm đích gần như có thể là bất cứ thứ gì |
| **BorgBackup** | Có, toàn bộ repository | Có, tốt nhất trong nhóm | Có, hỗ trợ gốc qua SSH | Một điểm đích Linux truy cập qua SSH. Không đối thủ khi dữ liệu lớn và lặp lại nhiều |
| **rsync kèm xoay vòng** | Không — điểm đích thấy mọi thứ | Một phần, qua hardlink | Không | Đồng bộ gương sang một máy bạn hoàn toàn kiểm soát, khi khôi phục từng phần tức thời quan trọng hơn quyền riêng tư |
| **rclone** | Chỉ khi dùng rclone crypt | Không | Tùy nhà cung cấp lưu trữ | Chuyển một kho lưu trữ đã có sẵn vào object storage, hoặc giữa các nhà cung cấp |
| **ZFS replication** | Chỉ khi dùng dataset đã mã hóa | Có, ở cấp block | Qua quyền snapshot | Nhân bản giữa hai máy ZFS. Rất nhanh, rất khắt khe ở cả hai đầu |
| **tar kèm age hoặc GPG** | Có, nếu bạn mã hóa kho lưu trữ | Không | Không áp dụng | Kho lưu trữ nhỏ, ít khi tạo, giữ vĩnh viễn, nơi sự đơn giản thắng hiệu suất |

Với một máy chủ đơn lẻ, dùng restic sao lưu sang một VPS thứ hai là con đường ngắn nhất để có được điều đúng đắn. Với một seedbox, một kho lưu trữ media, hay bất cứ thứ gì có nhiều file lớn tương tự nhau, khả năng khử trùng lặp của Borg chính là khác biệt giữa một ổ đĩa đầy ắp và một ổ đĩa thoải mái — [hướng dẫn seedbox](https://servhidden.com/vi/guides/seedbox-setup-guide) của chúng tôi trình bày chi tiết hơn khía cạnh lưu trữ của khối lượng công việc đó.

## Bất cứ thứ gì đang chạy đều không phải là một file

Bản sao lưu hỏng phổ biến nhất trên thế giới là một bản copy file thẳng của một cơ sở dữ liệu đang chạy sống. Nó hoàn tất mà không báo lỗi, nặng đúng dung lượng mong đợi, rồi khi khôi phục lại thành một bảng mà engine từ chối mở. Cơ sở dữ liệu đang giữa lúc ghi khi bản copy đi qua; thứ bạn lưu được chỉ là một bức ảnh chụp lại khoảnh khắc lật trang.

Có ba cách thoát khỏi tình trạng này, theo thứ tự công sức tăng dần. Dump nó ra: mysqldump --single-transaction cho ra một bản dump InnoDB nhất quán mà không khóa các tiến trình ghi, và pg_dump làm điều tương tự cho PostgreSQL. Snapshot nó: đóng băng hệ thống file hoặc chụp một snapshot LVM hay ZFS, copy từ snapshot đó, rồi giải phóng nó — đây là cách xử lý các tập dữ liệu quá lớn để dump mỗi đêm. Hoặc dừng nó lại: với một dịch vụ nhỏ, hai phút downtime lúc 04:00 sáng là một chiến lược đảm bảo tính nhất quán hoàn toàn đáng tin cậy, và đó là cách duy nhất không có trường hợp ngoại lệ.

Logic tương tự cũng áp dụng ngoài phạm vi cơ sở dữ liệu. Lớp ghi được của một container là thứ dùng-rồi-bỏ, nhưng các volume của nó thì không, và file docker compose cùng phần môi trường đi kèm cũng vậy — một bản sao lưu khôi phục được dữ liệu nhưng không khôi phục được định nghĩa sẽ khiến bạn phải dựng lại cả stack bằng trí nhớ. Hàng đợi tin nhắn, Redis bật chế độ persistence, và một mail spool đang được một MTA ghi vào đều xứng đáng được đối xử như nhau: tạm dừng, chụp snapshot, hoặc dump ra, nhưng đừng bao giờ copy thẳng rồi cầu may.

## Cần sao lưu những gì, và những phần mà ai cũng quên

Hầu hết mọi người sao lưu phần dữ liệu hiển nhiên — cơ sở dữ liệu và thư mục ứng dụng — rồi dựng lại phần còn lại bằng tay trong lúc áp lực. Việc dựng lại đó chính là nơi ngốn hết thời gian. Một bản sao lưu đưa bạn về một hệ thống hoạt động được, chứ không phải chỉ về một đống dữ liệu đúng, cần bao gồm cả lớp nhàm chán:

- Toàn bộ /etc, cộng với các unit và timer systemd bạn đã viết, cùng mọi crontab nằm ngoài thư mục đó.

- Chứng chỉ TLS và khóa riêng của chúng, hoặc tối thiểu là khóa tài khoản ACME, để chứng chỉ có thể gia hạn thay vì phải làm lại từ đầu.

- Quy tắc tường lửa và danh sách gói phần mềm, hai thứ này cùng nhau dựng lại hình hài máy chủ nhanh hơn bất kỳ trí nhớ nào.

- Secret của ứng dụng và các file môi trường — những thứ bị cố tình loại khỏi code repository, và vì vậy không tồn tại ở nơi nào khác.

- Bản ghi DNS xuất ra dạng văn bản, bao gồm cả reverse-DNS và các bản ghi PTR, vốn nằm ở phía nhà cung cấp chứ không phải trên máy chủ.

**Một số khóa không phải là dữ liệu — chúng là danh tính.** Khóa riêng của một dịch vụ onion trên Tor *chính là* địa chỉ: mất nó thì trang web không thể quay lại với cùng [tên .onion](https://servhidden.com/vi/guides/how-to-host-a-tor-hidden-service), dù bạn có khôi phục được mọi thứ khác. Một khóa server WireGuard đồng nghĩa với việc phải cấp lại mọi cấu hình client bạn từng phát ra. Khóa DKIM của một mail server đồng nghĩa với một selector mới và phải làm lại từ đầu về [khả năng gửi thư đến hộp thư đến](https://servhidden.com/vi/guides/offshore-mail-server-setup). Seed và trạng thái channel của một node Lightning có thể đồng nghĩa với tiền, không chỉ là file — [hướng dẫn vận hành node](https://servhidden.com/vi/guides/crypto-node-hosting-guide) nói rõ điều này. Hãy sao lưu các khóa này riêng biệt, giữ chúng ngoại tuyến, và coi chúng quý giá hơn cả dữ liệu mà chúng bảo vệ.

## Một bản khôi phục chưa được kiểm chứng chỉ là lời đồn

Phần mềm sao lưu tự báo cáo về chính nó, và nó báo cáo trung thực về đúng thứ không quan trọng. "Snapshot completed" chỉ có nghĩa là dữ liệu đã được ghi vào một repository. Nó không nói gì về việc repository đó có thể đọc được trên một máy khác hay không, bởi một người không còn nhớ họ đã cấu hình những gì mười một tháng trước.

Hãy bắt đầu với các kiểm tra tính toàn vẹn ít tốn kém — restic check --read-data-subset=5% hoặc borg check --verify-data theo lịch trình — và hiểu rằng chúng chỉ xác minh kho lưu trữ, không xác minh khả năng bạn dùng được nó. Bài kiểm tra thật sự khác hẳn và chỉ tốn một buổi chiều, làm một lần. Hãy thuê một máy chủ mới tính theo giờ ở một địa điểm bạn không dùng cho việc khác. Khôi phục lên đó chỉ với địa chỉ repository, cụm mật khẩu, và ghi chú của riêng bạn. Đưa dịch vụ chạy lên lại. Đo thời gian toàn bộ quá trình. Rồi hủy máy chủ đó. Tổng chi phí: vài đô la, và đây là bài tập duy nhất cho ra một con số bạn có thể tin tưởng.

Thứ mà nó luôn phơi bày ra không bao giờ là dữ liệu. Đó là gói phần mềm bị thiếu mà không ai ghi lại, cấu hình nằm ngoài các đường dẫn được sao lưu, cụm mật khẩu chỉ từng tồn tại trong lịch sử shell của chính máy chủ bạn đang cố thay thế, và phiên bản công cụ có thể đọc được định dạng repository của bạn. Mỗi thứ trong số đó đều tầm thường để sửa trước, nhưng khốn khổ nếu phát hiện ra giữa lúc sự cố đang xảy ra.

Hãy ghi lại hai con số mà bài tập này cho bạn: khôi phục mất bao lâu, và lịch trình sao lưu có thể mất tối đa bao nhiêu công việc. Đó chính là chính sách sao lưu. Mọi thứ ở trên chỉ là chi tiết triển khai phục vụ cho hai con số đó.

## Tự động hóa để nó cứ tiếp tục diễn ra

Hãy chạy tác vụ này từ một systemd timer thay vì cron. Bạn sẽ có log tập trung một chỗ, một bản ghi thật về lần chạy gần nhất, và một lịch trình sống sót qua cả reboot — những thứ cron không cho bạn nếu không phải tốn thêm công sức. Đừng để cụm mật khẩu nằm trong chính file unit, vì bất kỳ ai có quyền truy cập shell đều có thể đọc thẳng nó ra bằng systemctl cat.

Sau đó, hãy xử lý kiểu lỗi thực sự khiến người ta gặp rắc rối, đó không phải là một lỗi mà là sự im lặng. Một bản sao lưu đã ngừng chạy từ sáu tuần trước trông y hệt như một bản chạy hoàn hảo, vì cả hai đều không cho ra bất kỳ output nào. **Hãy cảnh báo khi vắng mặt, không phải khi thất bại.** Hãy để tác vụ ping tới một monitor mỗi khi thành công, và để monitor đó lên tiếng khi tín hiệu ping không đến — và đặt monitor đó ở bất cứ đâu ngoại trừ chính máy chủ mà nó theo dõi, vì một máy đã sập thì không thể tự báo rằng nó đã sập.

Hãy đặt thời gian lưu giữ một cách có chủ đích thay vì dùng mặc định. Một thiết lập như --keep-daily 7 --keep-weekly 4 --keep-monthly 6 bao phủ được cả những sai sót bạn nhận ra ngay đêm nay lẫn hỏng hóc bạn chỉ nhận ra vào mùa xuân, mà không phình to mãi mãi. Hãy chạy việc dọn dẹp ở phía điểm đích nếu bạn đã chuyển sang append-only, đó chính là mục đích của việc chuyển sang append-only. Dung lượng truyền tải hiếm khi là giới hạn trên mạng của chúng tôi — băng thông không giới hạn trên mọi gói — nên hãy lên lịch vì tính nhất quán chứ không phải vì một hạn mức, và đối chiếu thời điểm chạy với những giờ yên tĩnh của riêng bạn. Các thói quen rộng hơn xoay quanh tất cả những điều này được trình bày trong [hướng dẫn OpSec máy chủ](https://servhidden.com/vi/guides/server-opsec-staying-anonymous).

## Bản tóm tắt

Nếu bạn không làm gì khác từ trang này, hãy làm sáu điều sau, gần đúng theo thứ tự này:

- Đặt một bản sao ở một nhà cung cấp thứ hai, tại một thẩm quyền pháp lý thứ hai, thanh toán riêng tư theo cùng cách như bản đầu tiên.

- Biến bản sao đó thành append-only, hoặc kéo nó từ điểm đích, để một máy chủ bị xâm nhập không thể phá hủy nó.

- Để công cụ mã hóa ngay tại nguồn, và giữ khóa ngoài cả hai máy có liên quan.

- Dump cơ sở dữ liệu và dừng hoặc chụp snapshot bất cứ thứ gì đang chạy; đừng bao giờ copy thẳng trạng thái đang sống.

- Sao lưu các khóa danh tính riêng biệt — onion, WireGuard, DKIM, seed của node — vì những thứ này không thể tạo lại được.

- Khôi phục lên một máy chủ dùng-rồi-bỏ một lần, đo thời gian, và ghi lại những gì còn thiếu.

Không điều nào trong số này kỳ lạ cả, và không điều nào tốn một cuối tuần. Đó chỉ là một buổi chiều thiết lập và một lần diễn tập, đối lại với một loại mất mát có thể kết liễu cả dự án. Trên một nền tảng cố tình không giữ gì về bạn, bản sao bạn tự làm ra là bản duy nhất tồn tại — đó là cái giá của sự sắp xếp này, và là một cái giá công bằng. [Dựng một máy chủ thứ hai](https://servhidden.com/vi/vps) ở một thẩm quyền pháp lý khác với thẩm quyền đầu tiên của bạn, và cho bản sao lưu tối nay một nơi để hạ cánh.





FAQ

## Sao lưu VPS — các câu hỏi thường gặp





### 01
ServHidden có sao lưu VPS của tôi không?



Không, và đó là chủ đích chứ không phải thiếu sót. Chính sách lưu trữ của chúng tôi nêu rõ: không có bản sao lưu nào được lưu giữ, dữ liệu máy chủ bị hủy trong vòng 24 giờ sau khi chấm dứt dịch vụ, và ổ đĩa được xóa bằng phương pháp mã hóa thay vì định dạng lại. Giữ lại một bản sao dữ liệu của bạn sau khi bạn đã yêu cầu xóa sẽ mâu thuẫn với chính lý do nền tảng này tồn tại. Mọi thứ bạn muốn giữ lại sau khi máy chủ mất đi đều phải do chính bạn sao chép ra ngoài, tốt nhất là sang một nhà cung cấp thứ hai ở một thẩm quyền pháp lý thứ hai.





### 02
Snapshot có giống với bản sao lưu không?



Không. Snapshot chia sẻ mọi vùng rủi ro với máy chủ mà nó xuất phát — cùng nhà cung cấp, cùng tài khoản, cùng quốc gia, thường cùng cả hệ thống lưu trữ. Nó rất xuất sắc để hoàn tác một bản nâng cấp bị lỗi, nhưng vô dụng trước việc mất tài khoản, mất nhà cung cấp hay mất máy chủ. Hãy coi snapshot như một nút hoàn tác, còn bản sao lưu như một khoản bảo hiểm; chúng giải quyết hai vấn đề khác nhau và bạn cần cả hai.





### 03
Nên dùng restic hay BorgBackup?



Chọn restic nếu điểm đích có thể là object storage, SFTP hoặc thứ gì đó bạn chưa quyết định, vì nó hỗ trợ nhiều back-end nhất. Chọn BorgBackup nếu điểm đích là một máy Linux duy nhất truy cập qua SSH và dữ liệu lớn, lặp lại nhiều, vì khả năng khử trùng lặp của nó mạnh nhất trong nhóm. Cả hai đều mã hóa ngay tại nguồn trước khi bất cứ thứ gì rời khỏi máy, và cả hai đều hỗ trợ điểm đích append-only — điều này quan trọng hơn nhiều so với việc chọn công cụ nào.





### 04
Làm sao để ngăn kẻ tấn công xóa bản sao lưu của tôi?



Hãy loại bỏ khả năng, thay vì cố loại bỏ động cơ. Hoặc biến điểm đích thành append-only, để thông tin xác thực trên máy chủ production có thể thêm dữ liệu nhưng không bao giờ xóa được; hoặc đảo ngược hướng kết nối để máy chủ sao lưu kéo dữ liệu từ production, còn production thì không giữ bất kỳ thông tin xác thực nào cả. Xóa bản sao lưu trước khi lộ diện là thông lệ chuẩn của bất kỳ ai làm việc này một cách chuyên nghiệp, và một bản sao mà kẻ tấn công có thể xóa thì không phải là bản sao thứ hai.





### 05
Bản sao thứ hai nên đặt ở đâu?



Ở một nhà cung cấp khác, tại một thẩm quyền pháp lý khác, và được thanh toán riêng tư như chính máy chủ production của bạn. Những sự cố xóa sổ cả hai bản sao cùng lúc hiếm khi là sự cố vật lý — đó là một tài khoản bị mất, một nhà cung cấp gặp tuần tồi tệ, hoặc một văn bản pháp lý có hiệu lực ở quốc gia này nhưng không ở quốc gia khác. Hai máy chủ trong cùng một rack chỉ là một bản sao với thêm vài bước. Vì các công cụ đã mã hóa ngay tại nguồn, máy chủ thứ hai không cần phải là nơi bạn tin tưởng.





### 06
Nên sao lưu bao lâu một lần?



Hãy suy ngược từ lượng công việc bạn sẵn sàng làm lại. Một blog có thể mất một ngày mà chẳng ai để ý; một cửa hàng thì không thể mất một giờ đơn hàng. Sao lưu mỗi đêm là mặc định hợp lý cho hầu hết các thiết lập một máy chủ, kèm dump cơ sở dữ liệu thường xuyên hơn nếu các thao tác ghi có giá trị. Điều quan trọng hơn tần suất là độ sâu lưu giữ: hỏng hóc thường chỉ được phát hiện sau vài tuần, nên hãy giữ đủ lịch sử để chạm tới một điểm trước khi sự cố bắt đầu.





### 07
Bản sao lưu đã mã hóa có an toàn trên một máy chủ tôi không kiểm soát không?



Về mặt nội dung thì có — restic và Borg mã hóa dữ liệu trước khi nó rời khỏi nguồn, nên điểm đích chỉ lưu các khối dữ liệu mà nó không đọc được, và khóa thì không bao giờ di chuyển tới đó. Thứ mà điểm đích biết được là metadata: khoảng bao nhiêu dữ liệu bạn đang giữ, nó thay đổi ra sao, và tác vụ của bạn chạy vào lúc nào. Điều này thường chấp nhận được. Nếu không, hãy thay đổi lịch chạy và đặt repository trên một máy có chủ sở hữu không liên hệ gì tới máy production.





### 08
Điều gì xảy ra nếu tôi làm mất cụm mật khẩu sao lưu?



Kho lưu trữ mất vĩnh viễn, không ai có thể cứu vãn được. Đây là kiểu mất mát hoàn toàn phổ biến nhất trong toàn bộ chủ đề này, và là sự cố duy nhất không có đường phục hồi. Hãy giữ cụm mật khẩu ở một nơi ngoài mọi máy có liên quan, ưu tiên giấy hơn là một tài khoản mà bạn cũng có thể mất quyền truy cập, và thêm một khóa thứ hai vào repository để một mật khẩu bị quên chỉ là một sự bất tiện chứ không phải dấu chấm hết cho kho lưu trữ.




Hướng dẫn liên quan

## Đọc tiếp


[### Cách chọn khu vực pháp lý offshore hosting năm 2026

Mua hàng


Khung quyết định thực tế để chọn khu vực pháp lý offshore: luật lưu giữ dữ liệu, rủi ro MLAT, lập trường với DMCA, tốc độ xử lý tòa án và thực thi thực tế — theo từng quốc gia.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/choosing-an-offshore-jurisdiction)
[### VPS vs máy chủ dedicated cho workload yêu cầu quyền riêng tư cao

Mua hàng


Khi nào VPS là đủ, khi nào việc chia sẻ tenancy là rủi ro, và khi nào bare metal là lựa chọn duy nhất thực sự đúng đắn. Cách ly phần cứng, rủi ro hypervisor, và chi phí so với mô hình mối đe dọa.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/vps-vs-dedicated-for-privacy)
[### VPN Tự Lưu Trữ trên VPS No-KYC: WireGuard vs OpenVPN

Vận hành


Tại sao VPN tự lưu trữ vượt trội hơn các nhà cung cấp thương mại, và WireGuard cùng OpenVPN thực sự so sánh như thế nào về quyền riêng tư, hiệu suất và rủi ro vận hành vào năm 2026.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 cho AI Inference (và Vị trí của RTX 5090)

Mua hàng


Hướng dẫn mua: GPU NVIDIA nào phù hợp cho workload LLM tự host, tạo ảnh, video, giọng nói và fine-tuning năm 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, khi nào mỗi loại thắng.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/rtx-4090-vs-h100-for-ai-inference)
[### Offshore Windows RDP cho Giao dịch Forex MT4 / MT5 / cTrader

Vận hành


Hướng dẫn toàn diện: tại sao cần Windows RDP cho giao dịch Forex, cách chọn khu vực pháp lý offshore có độ trễ thấp, cài đặt MT4 / MT5 / cTrader / Expert Advisor, độ trễ đến máy chủ broker, và quy trình thanh toán không KYC.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/offshore-windows-rdp-for-forex-trading)
[### Giải thích Hosting Bỏ qua DMCA: Thực sự có Nghĩa gì vào năm 2026

Mua hàng


Hosting "bỏ qua DMCA" thực sự mang lại gì cho bạn, những khu vực pháp lý nào thực sự hỗ trợ nó, các khối lượng công việc cần đến nó, và những bẫy bản quyền mà thuật ngữ này không bao gồm.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/dmca-ignored-hosting-explained)
[### Đăng ký tên miền ẩn danh bằng Crypto: WHOIS Privacy năm 2026

Quyền riêng tư


Hướng dẫn thực tế năm 2026 về đăng ký tên miền mà không tiết lộ danh tính: các chế độ WHOIS theo TLD, lựa chọn registrar, tùy chọn thanh toán bằng crypto, và những sai lầm vận hành vẫn có thể làm lộ bạn.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/anonymous-domain-registration-with-crypto)
[### Thanh toán Crypto cho Hosting: Monero vs Bitcoin vs USDT

Quyền riêng tư


Việc chọn đồng coin thanh toán ảnh hưởng như thế nào đến những gì nhà cung cấp hosting biết về bạn. Quyền riêng tư, phí giao dịch, tính chung cuộc và mức độ phơi lộ trước phân tích blockchain cho XMR, BTC và USDT — kèm khuyến nghị rõ ràng.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Hosting Offshore Có Thực Sự Ẩn Danh Không? Câu Trả Lời Trung Thực

Quyền riêng tư


Hosting offshore, không yêu cầu KYC, loại bỏ danh tính mà một nhà cung cấp thông thường thu thập — nhưng "ẩn danh" còn phụ thuộc vào cách thanh toán, việc ghi log của nhà cung cấp và opsec của chính bạn. Đây là những gì thực sự có thể bị truy vết.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/is-offshore-hosting-truly-anonymous)
[### Giờ Đầu Tiên Gia Cố VPS: Một Checklist

Vận hành


Một checklist cụ thể, theo thứ tự, để bảo mật một VPS mới trong chưa đầy một giờ: khóa SSH, firewall, fail2ban, cập nhật tự động, và việc thu hẹp attack surface giúp chặn phần lớn các cuộc tấn công cơ hội.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/first-hour-vps-hardening-checklist)
[### What Is No-KYC Hosting? Definition, Legality & How It Works

Quyền riêng tư


No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/what-is-no-kyc-hosting)
[### Is Offshore Hosting Legal? The Honest 2026 Answer

Mua hàng


Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/is-offshore-hosting-legal)
[### How to Pay for Hosting with Monero (XMR) — Step by Step

Quyền riêng tư


A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/how-to-pay-for-hosting-with-monero)
[### How to Host a Website Anonymously — A Practical 2026 Guide

Quyền riêng tư


A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/how-to-host-a-website-anonymously)
[### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide

Vận hành


Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### How to Self-Host an LLM on a GPU Server — 2026 Guide

Vận hành


Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — What Is the Difference?

Mua hàng


Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/bulletproof-vs-offshore-hosting)
[### How to Buy a VPS with Bitcoin — Step-by-Step (2026)

Mua hàng


A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/how-to-buy-a-vps-with-bitcoin)
[### Best Countries for DMCA-Ignored Hosting in 2026

Mua hàng


Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/best-countries-for-dmca-ignored-hosting)
[### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide

Vận hành


Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/how-to-host-a-tor-hidden-service)
[### Offshore Mail Server Setup — Self-Host Private Email in 2026

Vận hành


Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/offshore-mail-server-setup)
[### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS

Vận hành


How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/crypto-node-hosting-guide)
[### GPU Hosting for Stable Diffusion — Run Your Own Image Server

Vận hành


Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Staying Anonymous When You Run a Server

Quyền riêng tư


Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/server-opsec-staying-anonymous)
[### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026

Vận hành


How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/seedbox-setup-guide)
[### How to Bypass DPI Censorship with Your Own VPS (2026 Guide)

Quyền riêng tư


Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough.


Câu hỏi thường gặp gồm 6 câu](https://servhidden.com/vi/guides/bypass-dpi-censorship-with-your-own-vps)
[### Mã hóa toàn bộ ổ đĩa trên VPS: cài đặt LUKS và giới hạn bảo vệ thực sự

Vận hành


Cách mã hóa VPS bằng LUKS: volume dữ liệu mã hóa, mã hóa toàn bộ root với mở khóa từ xa qua SSH, các cài đặt quan trọng trên server nhỏ, và đánh giá trung thực về những gì mã hóa ổ đĩa thực sự ngăn chặn được.


Câu hỏi thường gặp gồm 8 câu](https://servhidden.com/vi/guides/full-disk-encryption-on-a-vps)
[### Ẩn IP Origin Server: CDN, Reverse Proxy Và Những Gì Vẫn Rò Rỉ

Quyền riêng tư


Có nên đặt CDN trước một server offshore: nó che giấu được gì, bàn khiếu nại bạn thừa hưởng, sáu cách một IP origin vẫn rò rỉ, và cách tự kiểm toán IP của bạn.


Câu hỏi thường gặp gồm 8 câu](https://servhidden.com/vi/guides/hiding-your-origin-server-ip)
[### Tự Dựng Server Matrix: Federation, Metadata Và Giới Hạn Của E2EE

Vận hành


Tự dựng server Matrix mang lại điều gì: so sánh Synapse với Conduit, server_name mà bạn không thể đổi, kho media ngốn hết ổ đĩa, và những gì federation vẫn để lộ ra.


Câu hỏi thường gặp gồm 8 câu](https://servhidden.com/vi/guides/self-host-a-matrix-server)
[### Cách di chuyển website sang hosting offshore không downtime

Vận hành


Thứ tự khiến việc di chuyển máy chủ trở nên nhàm chán: hạ TTL của DNS trước nhiều ngày, chạy song song hai máy chủ, đóng băng ghi dữ liệu trong vài phút thay vì vài giờ — và dọn sạch dấu vết passive DNS, Certificate Transparency và WHOIS mà cuộc di chuyển để lại phía sau.


Câu hỏi thường gặp gồm 8 câu](https://servhidden.com/vi/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Vận hành


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


Câu hỏi thường gặp gồm 8 câu](https://servhidden.com/vi/guides/self-host-a-crypto-payment-gateway)




## Cho bản sao lưu tối nay một nơi để hạ cánh



Bảy thẩm quyền pháp lý, băng thông không giới hạn trên mọi gói, và máy chủ từ 7,50 $/tháng đủ sức làm điểm đích cho restic hay Borg. Không KYC, không cần email, chỉ thanh toán bằng crypto — cho điểm sao lưu cũng như cho production.


[Xem các gói VPS](https://servhidden.com/vi/vps)
[Máy chủ Dedicated](https://servhidden.com/vi/dedicated)
[Tất cả khu vực](https://servhidden.com/vi/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS offshore & máy chủ chuyên dụng tại 7 khu vực pháp lý offshore. Không KYC, không lưu nhật ký, chỉ chấp nhận crypto. Quyền riêng tư theo kiến trúc.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Chiến lược sao lưu VPS: mã hóa, ngoài máy chủ, khôi phục được",
    "description": "Nhà cung cấp không giữ bản sao lưu nào. Điều gì thực sự phá hủy máy chủ, vì sao sao lưu kiểu push chết theo máy chủ, restic hay Borg, và cách kiểm tra khôi phục.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "vi",
    "keywords": "sao lưu VPS, sao lưu VPS mã hóa, restic hay BorgBackup, sao lưu ngoài máy chủ, quy tắc sao lưu 3-2-1, sao lưu append-only, sao lưu VPS không KYC, kiểm tra khôi phục dữ liệu",
    "articleSection": "Vận hành",
    "wordCount": 7007
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "ServHidden có sao lưu VPS của tôi không?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Không, và đó là chủ đích chứ không phải thiếu sót. Chính sách lưu trữ của chúng tôi nêu rõ: không có bản sao lưu nào được lưu giữ, dữ liệu máy chủ bị hủy trong vòng 24 giờ sau khi chấm dứt dịch vụ, và ổ đĩa được xóa bằng phương pháp mã hóa thay vì định dạng lại. Giữ lại một bản sao dữ liệu của bạn sau khi bạn đã yêu cầu xóa sẽ mâu thuẫn với chính lý do nền tảng này tồn tại. Mọi thứ bạn muốn giữ lại sau khi máy chủ mất đi đều phải do chính bạn sao chép ra ngoài, tốt nhất là sang một nhà cung cấp thứ hai ở một thẩm quyền pháp lý thứ hai."
            }
        },
        {
            "@type": "Question",
            "name": "Snapshot có giống với bản sao lưu không?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Không. Snapshot chia sẻ mọi vùng rủi ro với máy chủ mà nó xuất phát — cùng nhà cung cấp, cùng tài khoản, cùng quốc gia, thường cùng cả hệ thống lưu trữ. Nó rất xuất sắc để hoàn tác một bản nâng cấp bị lỗi, nhưng vô dụng trước việc mất tài khoản, mất nhà cung cấp hay mất máy chủ. Hãy coi snapshot như một nút hoàn tác, còn bản sao lưu như một khoản bảo hiểm; chúng giải quyết hai vấn đề khác nhau và bạn cần cả hai."
            }
        },
        {
            "@type": "Question",
            "name": "Nên dùng restic hay BorgBackup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Chọn restic nếu điểm đích có thể là object storage, SFTP hoặc thứ gì đó bạn chưa quyết định, vì nó hỗ trợ nhiều back-end nhất. Chọn BorgBackup nếu điểm đích là một máy Linux duy nhất truy cập qua SSH và dữ liệu lớn, lặp lại nhiều, vì khả năng khử trùng lặp của nó mạnh nhất trong nhóm. Cả hai đều mã hóa ngay tại nguồn trước khi bất cứ thứ gì rời khỏi máy, và cả hai đều hỗ trợ điểm đích append-only — điều này quan trọng hơn nhiều so với việc chọn công cụ nào."
            }
        },
        {
            "@type": "Question",
            "name": "Làm sao để ngăn kẻ tấn công xóa bản sao lưu của tôi?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Hãy loại bỏ khả năng, thay vì cố loại bỏ động cơ. Hoặc biến điểm đích thành append-only, để thông tin xác thực trên máy chủ production có thể thêm dữ liệu nhưng không bao giờ xóa được; hoặc đảo ngược hướng kết nối để máy chủ sao lưu kéo dữ liệu từ production, còn production thì không giữ bất kỳ thông tin xác thực nào cả. Xóa bản sao lưu trước khi lộ diện là thông lệ chuẩn của bất kỳ ai làm việc này một cách chuyên nghiệp, và một bản sao mà kẻ tấn công có thể xóa thì không phải là bản sao thứ hai."
            }
        },
        {
            "@type": "Question",
            "name": "Bản sao thứ hai nên đặt ở đâu?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Ở một nhà cung cấp khác, tại một thẩm quyền pháp lý khác, và được thanh toán riêng tư như chính máy chủ production của bạn. Những sự cố xóa sổ cả hai bản sao cùng lúc hiếm khi là sự cố vật lý — đó là một tài khoản bị mất, một nhà cung cấp gặp tuần tồi tệ, hoặc một văn bản pháp lý có hiệu lực ở quốc gia này nhưng không ở quốc gia khác. Hai máy chủ trong cùng một rack chỉ là một bản sao với thêm vài bước. Vì các công cụ đã mã hóa ngay tại nguồn, máy chủ thứ hai không cần phải là nơi bạn tin tưởng."
            }
        },
        {
            "@type": "Question",
            "name": "Nên sao lưu bao lâu một lần?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Hãy suy ngược từ lượng công việc bạn sẵn sàng làm lại. Một blog có thể mất một ngày mà chẳng ai để ý; một cửa hàng thì không thể mất một giờ đơn hàng. Sao lưu mỗi đêm là mặc định hợp lý cho hầu hết các thiết lập một máy chủ, kèm dump cơ sở dữ liệu thường xuyên hơn nếu các thao tác ghi có giá trị. Điều quan trọng hơn tần suất là độ sâu lưu giữ: hỏng hóc thường chỉ được phát hiện sau vài tuần, nên hãy giữ đủ lịch sử để chạm tới một điểm trước khi sự cố bắt đầu."
            }
        },
        {
            "@type": "Question",
            "name": "Bản sao lưu đã mã hóa có an toàn trên một máy chủ tôi không kiểm soát không?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Về mặt nội dung thì có — restic và Borg mã hóa dữ liệu trước khi nó rời khỏi nguồn, nên điểm đích chỉ lưu các khối dữ liệu mà nó không đọc được, và khóa thì không bao giờ di chuyển tới đó. Thứ mà điểm đích biết được là metadata: khoảng bao nhiêu dữ liệu bạn đang giữ, nó thay đổi ra sao, và tác vụ của bạn chạy vào lúc nào. Điều này thường chấp nhận được. Nếu không, hãy thay đổi lịch chạy và đặt repository trên một máy có chủ sở hữu không liên hệ gì tới máy production."
            }
        },
        {
            "@type": "Question",
            "name": "Điều gì xảy ra nếu tôi làm mất cụm mật khẩu sao lưu?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Kho lưu trữ mất vĩnh viễn, không ai có thể cứu vãn được. Đây là kiểu mất mát hoàn toàn phổ biến nhất trong toàn bộ chủ đề này, và là sự cố duy nhất không có đường phục hồi. Hãy giữ cụm mật khẩu ở một nơi ngoài mọi máy có liên quan, ưu tiên giấy hơn là một tài khoản mà bạn cũng có thể mất quyền truy cập, và thêm một khóa thứ hai vào repository để một mật khẩu bị quên chỉ là một sự bất tiện chứ không phải dấu chấm hết cho kho lưu trữ."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Trang chủ",
            "item": "https://servhidden.com/vi/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Hướng Dẫn Privacy Hosting",
            "item": "https://servhidden.com/vi/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Chiến lược sao lưu VPS: mã hóa, ngoài máy chủ, khôi phục được",
            "item": "https://servhidden.com/vi/guides/vps-backup-strategy"
        }
    ]
}
```