Backup code bằng SSD di động: cách làm đúng để không mất dữ liệu

Laptop hỏng ổ, bị trộm hay dính ransomware, và một tháng code chưa kịp push biến mất. Chuyện này xảy ra nhiều hơn bạn nghĩ. Một chiếc SSD di động nhỏ bằng thẻ ATM là cách rẻ và nhanh nhất để có thêm một bản sao, nhưng chỉ khi bạn dùng nó đúng cách. Bài này nói rõ cần chọn ổ thế nào, format ra sao, sao lưu bằng công cụ gì và những cái bẫy khiến bản backup tưởng có mà thật ra không dùng được.

Vì sao "đã có Git" vẫn chưa phải là backup

Nhiều lập trình viên nghĩ code đã nằm trên GitHub hay GitLab thì không cần sao lưu nữa. Thực tế, Git remote chỉ giữ những gì bạn đã commit và push. Những thứ sau thường không có trên đó:

• Nhánh local chưa push, stash, commit đang làm dở.
• File .env, khoá SSH, chứng chỉ, file cấu hình máy, vốn được .gitignore loại ra một cách có chủ đích.
• Database dev, dữ liệu mẫu, file thiết kế, ghi chú, script cá nhân.
• Dự án freelance hay dự án cũ chưa từng được đưa lên remote.

Ngoài ra, tài khoản cũng có thể bị khoá, repo bị xoá nhầm, hay tổ chức đổi nền tảng. Git là công cụ quản lý phiên bản, còn backup là một bản sao độc lập mà bạn tự kiểm soát. Hai thứ bổ sung cho nhau chứ không thay thế nhau.

Quy tắc 3-2-1 và vị trí của SSD di động

Quy tắc kinh điển của ngành sao lưu là 3-2-1:

SSD di động giải quyết chữ "2": bản sao nằm trên một thiết bị vật lý tách biệt, khôi phục với tốc độ cao mà không cần Internet. Nhưng nếu bạn để SSD cắm suốt ngày cạnh laptop, một vụ cháy, mất trộm hay ransomware có thể lấy đi cả hai cùng lúc. Vì thế SSD nên được rút ra sau khi sao lưu xong, và tốt nhất có thêm một bản trên cloud.

Chọn SSD di động: tiêu chí quan trọng hơn tốc độ

Với việc sao lưu code, tốc độ đọc ghi quảng cáo không phải yếu tố quyết định. Thư mục dự án thường gồm hàng chục nghìn file nhỏ, nên độ trễ và hệ thống file ảnh hưởng nhiều hơn băng thông tối đa. Những tiêu chí đáng quan tâm:

• Dung lượng: ít nhất gấp đôi tổng dữ liệu cần sao lưu, để còn chỗ cho các phiên bản cũ (snapshot). Code thuần thì nhỏ, nhưng database dev, ảnh Docker hay asset thiết kế lớn rất nhanh.
• Cổng kết nối: USB-C với chuẩn USB 3.2 Gen 2 (10 Gbps) là đủ cho hầu hết nhu cầu. Kiểm tra cổng trên laptop có ký hiệu SS (SuperSpeed) hay biểu tượng tia sét Thunderbolt; cắm vào cổng USB 2.0 thì tốc độ sẽ tụt hẳn.
• Độ bền vật lý: vỏ cao su chống va đập, có chuẩn chống nước bụi nếu bạn hay mang theo.
• Mã hoá phần cứng hoặc khả năng mã hoá bằng phần mềm: vì ổ chứa khoá và bí mật của dự án.
• Nguồn mua đáng tin: SSD giả khai khống dung lượng khá phổ biến. Ổ giả vẫn nhận đủ dung lượng nhưng ghi quá ngưỡng thật thì dữ liệu bị ghi đè âm thầm.

Nếu đã có sẵn một SSD NVMe M.2 tháo ra khi nâng cấp máy, bạn có thể mua hộp đựng (enclosure) USB-C để biến nó thành SSD di động. Chỉ cần chọn hộp có tản nhiệt tốt, vì NVMe nóng lên nhanh khi ghi liên tục.

Format ổ: chọn hệ thống file đúng ngay từ đầu

Đây là bước nhiều người bỏ qua. Phần lớn SSD di động xuất xưởng với exFAT để cắm được trên mọi hệ điều hành. exFAT tiện nhưng có nhược điểm lớn cho việc sao lưu: không có journaling, nên rút ổ khi đang ghi hoặc mất điện dễ làm hỏng cấu trúc thư mục. exFAT cũng không giữ quyền thực thi và symlink kiểu Unix, thứ mà các dự án Node, Python hay script shell dùng thường xuyên.

Lời khuyên: nếu ổ chỉ dùng để backup cho một máy, hãy format sang hệ thống file gốc của máy đó. Nếu bắt buộc dùng chung nhiều hệ điều hành, hãy sao lưu dưới dạng file lưu trữ (repo backup của restic, file .tar hay git bundle) thay vì chép thẳng cây thư mục, như vậy symlink và quyền file vẫn được giữ bên trong.

Ba cách sao lưu code lên SSD, từ đơn giản đến chuyên nghiệp

Cách 1: git bundle cho từng repo

git bundle đóng gói toàn bộ lịch sử, mọi nhánh và tag của repo vào một file duy nhất. File này dùng được như một remote: clone, fetch đều được.

# Tạo bundle chứa mọi nhánh và tag
cd ~/projects/my-app
git bundle create /Volumes/BACKUP/my-app.bundle --all

# Kiểm tra bundle có hợp lệ không
git bundle verify /Volumes/BACKUP/my-app.bundle

# Khôi phục khi cần
git clone /Volumes/BACKUP/my-app.bundle my-app-restored

Ưu điểm là một file duy nhất, không lo hệ thống file làm hỏng symlink. Nhược điểm là bundle chỉ chứa những gì đã commit, nên file .env hay thay đổi chưa commit vẫn phải sao lưu riêng.

Cách 2: rsync đồng bộ cả thư mục

rsync chép những file thay đổi, nhanh với thư mục lớn. Nhớ loại bỏ các thư mục sinh ra được như node_modules, .venv, dist, target; chúng chiếm phần lớn dung lượng và hàng chục nghìn file nhỏ mà không cần sao lưu.

rsync -a --info=progress2 \
  --exclude node_modules --exclude .venv --exclude dist --exclude target \
  ~/projects/ /media/$USER/BACKUP/projects/

Cách 3: công cụ backup có snapshot và mã hoá

Để có lịch sử nhiều phiên bản, hãy dùng công cụ chuyên dụng như restic hoặc BorgBackup. Chúng chia dữ liệu thành khối, khử trùng lặp (khối giống nhau chỉ lưu một lần), mã hoá mặc định và cho phép quay lại bất kỳ thời điểm sao lưu nào.

# Khởi tạo kho backup mã hoá trên SSD (chỉ làm một lần)
restic -r /media/$USER/BACKUP/restic init

# Sao lưu, bỏ qua thư mục sinh ra được
restic -r /media/$USER/BACKUP/restic backup ~/projects \
  --exclude node_modules --exclude .venv

# Xem các snapshot và giữ lại 7 bản ngày, 4 bản tuần, 6 bản tháng
restic -r /media/$USER/BACKUP/restic snapshots
restic -r /media/$USER/BACKUP/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Người dùng Mac có thể dùng Time Machine trên ổ APFS; người dùng Windows có File History. Cả hai đều lưu nhiều phiên bản và đủ dùng nếu bạn nhớ loại trừ thư mục phụ thuộc.

Mã hoá: SSD di động rất dễ thất lạc

Một ổ nhỏ bằng thẻ ATM chứa khoá API, khoá SSH và mã nguồn của khách hàng là rủi ro bảo mật thật sự nếu để quên trên quán cà phê. Hãy mã hoá ổ ngay từ đầu:

• Windows: BitLocker To Go (có trên bản Pro trở lên).
• macOS: format APFS (Encrypted) trong Disk Utility.
• Linux: LUKS qua cryptsetup, hoặc VeraCrypt nếu cần mở trên nhiều hệ điều hành.
• Hoặc dùng restic, Borg vì chúng đã mã hoá kho backup sẵn.

Lưu mật khẩu mã hoá trong trình quản lý mật khẩu. Quên mật khẩu đồng nghĩa với mất backup, không có cách khôi phục.

Những sai lầm khiến bản backup trở nên vô dụng

Rút ổ không eject. Hệ điều hành thường gom dữ liệu vào bộ nhớ đệm rồi mới ghi xuống ổ. Rút cáp khi thanh tiến trình đã chạy xong vẫn có thể làm mất phần dữ liệu cuối, nhất là với exFAT. Luôn bấm Eject hoặc chạy sync rồi umount trước.

Cất SSD trong ngăn kéo nhiều năm. SSD lưu dữ liệu bằng điện tích trong ô nhớ flash, và điện tích rò rỉ dần khi không cấp điện. Tiêu chuẩn JEDEC JESD218 yêu cầu SSD dân dụng giữ được dữ liệu ít nhất 1 năm ở 30°C khi đã tiêu hao hết tuổi thọ ghi định mức. Ổ còn mới thì giữ lâu hơn nhiều, nhưng SSD không phải phương tiện lưu trữ lạnh lý tưởng. Hãy cắm ổ và chạy backup định kỳ, ví dụ hàng tuần, vừa cập nhật dữ liệu vừa cho ổ được cấp điện.

Không bao giờ thử khôi phục. Bản backup chưa từng được khôi phục thử thì chưa chắc dùng được. Mỗi tháng hãy chọn ngẫu nhiên một dự án, khôi phục ra thư mục tạm, chạy npm install hay pip install rồi build thử.

restic -r /media/$USER/BACKUP/restic check
restic -r /media/$USER/BACKUP/restic restore latest --target /tmp/restore-test

Chỉ có một ổ. SSD cũng có thể hỏng đột ngột, khác với HDD thường có dấu hiệu báo trước như tiếng kêu lạ. Dữ liệu quan trọng nên có thêm bản trên cloud hoặc ổ thứ hai để ở chỗ khác.

Quy trình mẫu mỗi tuần

• [ ]Commit và push mọi nhánh đang làm.
• [ ]Cắm SSD, mở khoá mã hoá.
• [ ]Chạy script backup (restic hoặc rsync) với danh sách loại trừ.
• [ ]Sao lưu riêng file .env, khoá SSH vào kho đã mã hoá.
• [ ]Eject an toàn rồi rút ổ, cất xa laptop.
• [ ]Mỗi tháng: khôi phục thử một dự án và chạy restic check.

Hãy gói các bước sao lưu vào một script shell, đặt lịch nhắc trong lịch làm việc. Backup chỉ có tác dụng khi nó trở thành thói quen, không phải việc làm khi chợt nhớ ra.

Bản backup tốt nhất là bản bạn đã khôi phục thử thành công ít nhất một lần.

Tóm tắt nhanh

• Git remote chỉ giữ code đã commit và push; .env, nhánh local, database dev cần sao lưu riêng.
• Theo quy tắc 3-2-1: SSD di động là bản thứ hai, cloud là bản ngoài site.
• Format ổ theo hệ điều hành chính (APFS, NTFS, ext4) hoặc sao lưu dạng kho lưu trữ nếu phải dùng exFAT.
• Dùng restic hoặc Borg để có snapshot, khử trùng lặp và mã hoá; loại trừ node_modules và thư mục build.
• Rút ổ sau khi backup, cắm lại định kỳ và khôi phục thử hàng tháng.

Câu hỏi thường gặp

SSD di động hay HDD gắn ngoài tốt hơn cho backup?

SSD nhanh, nhỏ gọn và chịu va đập tốt hơn, hợp với việc mang theo và sao lưu thường xuyên. HDD rẻ hơn trên mỗi TB, hợp làm kho lưu trữ dung lượng lớn để ở nhà. Nhiều người dùng cả hai.

Có cần sao lưu thư mục node_modules không?

Không. Thư mục này tạo lại được từ package.json và file lock. Hãy chắc chắn file lock (package-lock.json, pnpm-lock.yaml, poetry.lock...) có trong backup để khôi phục đúng phiên bản thư viện.

Để SSD cắm liên tục và backup tự động mỗi giờ có được không?

Được về mặt kỹ thuật, nhưng ổ đang cắm sẽ chịu chung rủi ro với máy: ransomware, sự cố điện hay mất trộm. Nếu muốn backup tự động liên tục, hãy kết hợp thêm một bản cloud hoặc một ổ thứ hai thường xuyên được rút ra.

Dùng chung một SSD vừa backup vừa chép phim được không?

Nên tách riêng. Hãy tạo một phân vùng hoặc dùng một ổ riêng cho backup, để tránh vô tình xoá hoặc ghi đè lên kho sao lưu khi dọn dẹp file khác.