- Ngay cả sau khi Time Capsule bị ngừng bán, bạn vẫn có thể tự dựng một thiết bị sao lưu luôn bật giá rẻ cho macOS bằng cách cài Linux lên phần cứng nhỏ, tiêu thụ điện thấp
- HP t520 giá 25 USD, gồm phí vận chuyển có CPU AMD G-Series lõi kép, RAM 4GB, SSD M.2 SATA 16GB, Ethernet 1Gbps và cổng USB 3.0, đủ dùng cho một máy chủ chuyên dụng đơn nhiệm
- Có thể chọn lưu trữ bằng SSD M.2 SATA bên trong hoặc ổ USB3 gắn ngoài; nếu dùng SSD M.2 SATA 2280 dung lượng 2TB thì tổng chi phí vào khoảng 94 USD
- Cài
netatalk và avahi-daemon trên Bodhi Linux để cấu hình chia sẻ Time Machine dựa trên AFP, nhưng sau khi bài viết được công bố, phần hướng dẫn dùng Samba đã được bổ sung vì AFP đã deprecated
- Bản sao lưu ban đầu 460GB ở tốc độ 2Mbit/s sẽ mất tới 21 ngày, nhưng nhờ Power Nap,
debug.lowpri_throttle_enabled=0 và đặt gần AP Wi-Fi, tốc độ được cải thiện lên 120Mbit/s, rút xuống còn 8 giờ
Ý tưởng ThinMachine thay thế Time Capsule
- Apple Time Machine là lý do thúc đẩy việc chuyển sang Mac vào năm 2007, và sau đó người dùng đã dùng Time Capsule để sao lưu không dây
- Time Capsule cũ hoạt động hơn 10 năm rồi hỏng, và macOS liên tục hiển thị thông báo rằng bản sao lưu đã quá cũ
- Ngay cả sau khi Apple ngừng bán Time Capsule, bạn vẫn có thể tự dựng một thiết bị sao lưu tương tự bằng cách cấu hình một máy chủ Linux
- Với một thiết bị chuyên dụng đơn nhiệm, luôn bật, phần cứng nhỏ, tiêu thụ điện thấp và đặt vừa trong tủ mạng Internet là phù hợp
- Raspberry Pi cũng có thể dùng, nhưng thời điểm đó khó mua; giá trên 80 USD, lại phải mua riêng vỏ và bộ nguồn nên không còn hấp dẫn về chi phí
- Phương án thay thế là chọn một thin client PC đã qua sử dụng, và mua HP t520 trên eBay với giá 25 USD gồm phí vận chuyển
Phần cứng và điện năng của HP t520
- Cấu hình cơ bản của HP t520 giá 25 USD đủ dùng làm máy chủ sao lưu đơn giản
- CPU AMD G-Series GX-212JC lõi kép 1.2GHz và Radeon R2E
- DDR3-1600 4GB
- SSD M.2 SATA 16GB
- Ethernet 1Gbps
- 2 cổng USB 3.0, 4 cổng USB 2.0
- 2 cổng DisplayPort, 1 cổng VGA
- Chân đế đặt dọc
- Adapter nguồn 18.5V và cáp
- Máy không có Wi-Fi, nhưng dự định đặt trong tủ mạng cạnh router nên không thành vấn đề; nếu cần có thể dùng khe mini PCIe còn trống
- Việc bổ sung Wi-Fi chưa được thử trực tiếp nên chưa xác nhận chắc chắn 100% là hoạt động
- t520 tiêu thụ 6W khi idle, và 10W trong các tình huống khác
- Nếu lấy giá điện trung bình 0.35 USD/kWh, chi phí chạy 24/7 ở mức 6W là khoảng 19 USD mỗi năm
- Các thin client khác như HP t610 có thể tiêu thụ trên 10W khi idle do chipset cũ hơn
- Raspberry Pi 4 được đo ở khoảng 4W
- OS mặc định là HP Thin Pro, một bản phân phối tùy biến dựa trên Tiny Core Linux
- HP Thin Pro có kèm client Citrix và VMWare
- Tiny Core Linux gốc cũng đã được thử, nhưng số lượng gói cung cấp quá hạn chế
Chọn lưu trữ sao lưu: SSD bên trong và USB3 gắn ngoài
- Dung lượng SSD bên trong được t520 hỗ trợ chính thức là 64GB, nhưng đây là thông số từ thời chưa có SSD M.2 lớn hơn
- Khe M.2 bên trong hỗ trợ form factor 2242 và 2260, còn SSD 2280 mặc định sẽ vướng loa
- Có thể tháo loa bằng cách nhấc mainboard lên rồi tháo 2 con ốc
- Trước khi lắp SSD 2280, cần dán băng keo lên các pad đồng và đường mạch lộ ra ở mặt sau SSD
- Vì không có vít cố định nên có khả năng SSD tuột khỏi socket, nhưng trong cấu hình thực tế đây không được xem là mối lo lớn
- Khe bên trong của t520 chỉ hỗ trợ SSD M.2 SATA
- SSD dung lượng lớn hiện nay đa phần là NVMe, nhưng khe này không dành cho PCIe/NVMe
- HP đã chọn nhầm loại connector, khiến SSD NVMe có thể cắm vừa về mặt vật lý
- Nếu cắm SSD NVMe, SSD, mainboard hoặc cả hai đều có thể bị hỏng
- Khi chọn lưu trữ bên trong, chênh lệch giá và form factor là rất lớn
- SSD M.2 SATA 2260 2TB có giá 149 USD trên Amazon
- SSD M.2 SATA 2280 2TB có giá từ 69 USD
- SSD SATA 2280 4TB nhảy lên mức 260 USD
- SSD M.2 SATA 2280 2TB được chọn đã hoạt động bình thường, đưa tổng chi phí của ThinMachine 2TB lên 94 USD
- Ổ USB3 gắn ngoài là một lựa chọn thay thế giúp giảm độ khó khi lắp đặt
- SSD 2.5 inch 4TB có giá từ 150 USD và cũng có thể chọn dung lượng lớn hơn
- Dễ tháo ổ ra để cất giữ hoặc kết nối với PC khác
- Không cần mở t520
- Nhược điểm là cần enclosure USB3 và ngoại hình không gọn gàng
Cài Bodhi Linux và cấu hình phân vùng
- Khi tìm một bản phân phối dựa trên Ubuntu nhưng có image cài đặt nhỏ, Bodhi Linux đã được chọn
- Bản HWE có dung lượng 837MB, lớn hơn bản tiêu chuẩn 5MB, và hỗ trợ phần cứng mới hơn
- Tải ISO Ubuntu khá chậm, nhưng có thể tải ISO Bodhi Linux nhanh chóng
- Quy trình cài đặt là cách boot USB thông thường
- Chuẩn bị USB dung lượng từ 1GB trở lên
- Ghi image ISO vào USB bằng Balena Etcher
- Cắm USB vào t520 và boot
- Làm theo trình cài đặt để cài Bodhi Linux lên SSD của t520
- SSD bên trong được chia tách giữa OS và dữ liệu sao lưu
/dev/sda1: efi, 1GB, phân vùng boot và phải là phân vùng đầu tiên/dev/sda2: ext4, 16GB, dùng để cài Bodhi Linux/dev/sda3: ext4, toàn bộ phần còn lại, phân vùng dữ liệu sao lưu
- Điểm mount cũng được tách rõ ràng
/dev/sda2 được mount vào thư mục gốc //dev/sda3 được mount vào /mnt/timemachine
- Sau khi cài, Bodhi Linux dùng hơn 5GB một chút trên SSD, nên cấp 16GB sẽ còn đủ chỗ để cài thêm công cụ
Tài khoản máy chủ Time Machine và cấu hình AFP
- Trước tiên, cập nhật các gói lên trạng thái mới nhất
sudo apt update && sudo apt dist-upgrade
- Cài các gói cần thiết để Time Machine hoạt động
sudo apt install procinfo netatalk avahi-daemon
- Avahi là triển khai mã nguồn mở của tính năng mạng zero-configuration tương tự Apple Bonjour, cho phép Mac nhìn thấy máy chủ thinmachine trên mạng
- Netatalk là triển khai mã nguồn mở của Apple Filing Protocol, có hỗ trợ Apple Time Machine
- Tạo tài khoản chuyên dụng
timemachine
- Tài khoản này không có quyền
root hay sudo và cũng không tạo thư mục /home
- Khi kết nối từ Mac tới máy chủ, dùng tên người dùng và mật khẩu này
- Mật khẩu này không phải là mật khẩu dùng để mã hóa dữ liệu sao lưu
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
- Chỉnh sửa
/etc/netatalk/afp.conf để cấu hình chia sẻ Time Machine
vol size limit có thể giới hạn dung lượng đĩa mà bản sao lưu Time Machine được dùng, tính theo MB- Ở đây dùng toàn bộ ổ đĩa cho Time Machine nên không chỉ định giới hạn dung lượng
hostname không nhất thiết phải trùng với hostname Unix, nhưng được dùng làm tên hiển thị trên mạng Bonjour
;
; Netatalk 3.x configuration file
;
[Global]
hostname = thinmachine
[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
- Kích hoạt và khởi động các daemon cần thiết
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
- Mở các cổng cần thiết trên firewall và khởi động lại Netatalk
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
- Cấu hình này dựa trên AFP, và sau khi bài viết được công bố, một ghi chú đã được bổ sung rằng AFP đã deprecated và nên dùng Samba
Khôi phục sau mất điện và kết nối Mac
- Appliance sao lưu cần tự bật lại khi có điện sau mất điện, nên cần đổi thiết lập BIOS
- Nhấn F10 ở giai đoạn đầu khi boot để vào thiết lập BIOS
- Vào
Advanced → Power-On Options
- Đặt
After Power Loss thành On
- Trong phần cài đặt Time Machine trên Mac, nhấn
Select Disk thì ThinMachine sẽ xuất hiện trong các lựa chọn
- Dữ liệu sao lưu được mã hóa trên Mac; thin client không tham gia vào quá trình mã hóa và giải mã
- Nếu mất mật khẩu sao lưu, sẽ không có cách khôi phục dữ liệu
- Lần sao lưu đầu tiên có thể mất nhiều thời gian
Cải thiện tốc độ sao lưu ban đầu
- MacBook có 460GB dữ liệu, và sao lưu Time Machine mang tính nguyên tử nên nếu chưa hoàn tất thì phải bắt đầu lại từ đầu
- Tốc độ sao lưu ban đầu khoảng 2Mbit/s, khiến toàn bộ bản sao lưu có thể mất khoảng 21 ngày
- Trong thời gian đó, nếu tắt/bật máy chủ hoặc laptop ra khỏi vùng phủ Wi-Fi, bản sao lưu phải làm lại từ đầu
- Bật Power Nap ngay cả khi đang dùng pin
- Khi Power Nap được bật, sao lưu Time Machine vẫn tiếp tục dù đóng laptop hoặc chạy bằng pin
- Nếu Power Nap tắt, sao lưu sẽ bị ngắt và bắt đầu lại
- Trong lúc chạy bản sao lưu đầy đủ đầu tiên, tắt giới hạn tiến trình nền
sudo sysctl debug.lowpri_throttle_enabled=0
- Thiết lập này tăng tốc độ sao lưu từ 2Mbit/s lên 20Mbit/s
- Sau bản sao lưu ban đầu, nên bật lại giới hạn
sudo sysctl debug.lowpri_throttle_enabled=1
- Khi chuyển laptop lại gần access point của mạng mesh Wi-Fi Eero, tốc độ tăng từ 20Mbit/s lên 120Mbit/s
- Nhờ thay đổi mức ưu tiên và đặt gần AP, thời gian sao lưu 460GB giảm từ 21 ngày xuống còn 8 giờ
Kết quả sử dụng và khả năng mở rộng thêm
- Sau vài ngày sử dụng, cảnh báo sao lưu cũ trên MacBook biến mất, và việc sao lưu chạy bình thường trong nền
- Có thể gắn thêm ổ vào t520 để mở rộng thành NAS, nhưng không thấy cần thiết
- Cũng có thể tạo bản sao đầy đủ định kỳ sang ổ gắn ngoài để phòng trường hợp ổ bên trong hỏng
- Vì đã dùng Backblaze làm dịch vụ sao lưu offsite, mức dự phòng như vậy được xem là đủ
1 bình luận
Ý kiến trên Hacker News
Tôi không còn tin Time Machine nữa. Vài năm trước tôi đã viết một shell script gần như tự động hóa toàn bộ cấu hình hệ thống bằng
brewvà các công cụ tương tự, rồi thỉnh thoảng xóa sạch hệ thống và khôi phục lại bằng script đóTôi dùng restic để sao lưu dữ liệu. Ưu điểm lớn là có thể đọc bản sao lưu ngay cả khi không có thiết bị macOS. Khi chiếc máy macOS duy nhất gặp sự cố phần cứng, bản sao lưu Time Machine về cơ bản vô dụng cho đến khi tôi kiếm được một máy Mac mới
Cách này không phù hợp với tất cả mọi người, nhưng vì Time Machine đã làm hỏng bản sao lưu của tôi hơn 5 lần và quá chậm so với restic, nên ngay cả khi có bản phát hành macOS mới tôi cũng không muốn thử lại
Tôi chỉ là người dùng đã dùng ổn suốt 9 năm, không phải người liên quan
[1] https://www.arqbackup.com
Giờ tôi dùng Carbon Copy Cloner, Syncthing và Arq. Nhờ vậy việc sao lưu cho gia đình nhanh hơn, tự nhiên hơn và dễ quản lý hơn rất nhiều
Nhưng trên macOS tôi có 2 tài khoản người dùng, tức tài khoản của tôi và của vợ/chồng tôi, mà tôi không thể khiến Restic truy cập dữ liệu của tài khoản kia. Tôi là quản trị viên, chạy bằng root và cũng đã cấp “Full Disk Access” nhưng vẫn không được. Tôi rất muốn biết mẹo nào đó
Ngay cả khi dùng
brewvàbrew cask, vẫn có nhiều ứng dụng GUI cần cài thủ công và cấu hình của chúng nằm rải rác ở nhiều nơi. Nếu tính cả các công cụ CLI hoặc nền được cài thủ công, cùng các thiết lập hệ thống, thì ngoài kiểu sao lưu Time Machine, tức gần như ảnh đĩa, tôi thật sự không biết cách nào hợp lý để tự động hóa việc khôi phục tất cả những thứ nàyCũng muốn biết liệu bạn có gặp cùng kiểu hỏng hóc đó trên bản APFS không
Tôi đang chạy Pi-hole và Time Machine trên Raspberry Pi, và đây có thể là món đồ công nghệ có tỷ lệ hiệu năng/giá tốt nhất tôi từng mua. Tôi đã làm theo https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-...
Nó đắt hơn, cần vỏ và bộ cấp nguồn riêng, không thể dùng SSD M.2 nếu không có vỏ USB3 bổ sung. Nó cũng có tiền sử hỏng thẻ flash, còn điện năng lúc nhàn rỗi thì chỉ thấp hơn đôi chút
Tôi đưa nó cho con gái mang lên đại học dùng, nhưng rất nghi ngờ là nó có thực sự dùng không, và trước khi đọc bài này tôi thậm chí còn không nghĩ đến chuyện hỏi
Để giữ gìn sức khỏe tinh thần, tôi khuyên nên ngừng dùng Time Machine và dùng Carbon Copy Cloner [0]. Nó hoạt động đúng, tiếp tục hoạt động ổn định, tài liệu cho các tình huống sao lưu/khôi phục có thể xảy ra rất xuất sắc, và cho thấy minh bạch nó đang làm gì.
Time Machine thì đang chạy tốt rồi đến một lúc nào đó lại không chạy nữa. Nó cũng không báo rằng bản sao lưu đã hỏng cho đến khi bạn thử khôi phục. Lỗi thì khó hiểu, không có hỗ trợ, diễn đàn cũng không giúp được gì, và bản sao lưu hỏng thì không sửa được. Time Machine áp dụng kiểu tiếp cận “mặc kệ người dùng chết dở” khi không cung cấp bất kỳ thông tin nào về việc nó đang làm gì, không làm gì hay định làm gì.
Nếu dữ liệu của bạn đáng để sao lưu thì đừng dùng Time Machine.
[0] https://bombich.com
Với iCloud cũng vậy, câu trả lời bạn nghe ở khắp nơi chỉ là “dữ liệu đang đồng bộ”, “thử tắt rồi bật lại”, “hãy khởi động lại”. Nhìn Apple Support tự tin bảo người ta reset iOS hoặc cài lại toàn bộ macOS chỉ vì một lỗi đồng bộ nhỏ, tôi có cảm giác như đang nói chuyện với một con bot hành hạ kiểu Kafka.
Đó là playbook của Apple. Chỉ trích công khai trên mạng xã hội cũng vô ích, email thì không được trả lời, yêu cầu của khách hàng thì bị chặn. Đôi khi tôi còn thấy như thể mình đang được trả tiền để dùng sản phẩm Apple vậy.
Khi quản lý cũ của tôi nói rằng cứ nhận máy Mac, dù dùng cá nhân hay công việc, việc đầu tiên ông ấy làm là cài Linux, người mới vào đều xem ông ấy là một kẻ cuồng GNU/FOSS kỳ quặc. Ông ấy chỉ cười và nói sau này rồi sẽ hiểu, và giờ thì tôi hiểu hệ sinh thái Apple bất lực và thù địch đến mức nào. Sau khi chịu đựng đủ những bức tường chặn đường và các giới hạn gây bực bội, bạn rơi vào trạng thái con tin, cảm thấy như đó là cách duy nhất.
Ở thời điểm này, tôi cho rằng nói Time Machine hay bất kỳ tính năng nào của Apple liên quan đến tính toàn vẹn và độ tin cậy của dữ liệu là “hoạt động tốt” hay “đủ ổn”, hoặc dựa vào thứ như iCloud cho sao lưu dữ liệu và tính toàn vẹn dữ liệu, gần như là tự hủy hoại bản thân.
Tôi đang chờ ngày việc truy cập tệp dưới quyền cho phép rõ ràng trên iOS trở nên dễ hơn, hoặc Android bớt tệ hơn. Cuối cùng thì vẫn phải ép cái thế song quyền huy hoàng này mở nền tảng ra, chứ họ sẽ không tự làm đâu.
Time Machine thì miễn phí và với phần lớn mọi người, cho sao lưu cục bộ hoặc qua mạng nội bộ, nó “đủ ổn”. Với sao lưu từ xa thì có BorgBase; Vorta, ứng dụng GUI borg, thì tệ khủng khiếp, và Backblaze là một lựa chọn tạm chấp nhận được.
Ngoài ra CCC có vẻ cũng không có bản sao lưu write-only bất biến ở phía client sau khi tạo như Borg, và trong danh sách tính năng tôi cũng không thấy mã hóa hay deduplication. https://bombich.com/features
Hiện giờ tôi dùng Time Machine để sao lưu cả máy chủ TrueNAS lẫn ổ đĩa cục bộ, nhưng chỉ khi tôi nhớ cắm nó vào. Thư mục home thì được sao lưu lên B2 bằng Arq.
Với gia đình tôi thì tôi cho họ dùng Backblaze. Đó thật sự là cách duy nhất có thể thiết lập xong rồi quên luôn. Người nhà tôi lúc nào cũng quên cắm ổ Time Machine cục bộ, còn nếu cấu hình Time Machine với ổ mạng thì cứ vài tháng lại trở chứng và họ chỉ phớt lờ thông báo của Time Machine rằng sao lưu không chạy được.
Backblaze thì gần như cứ thế mà chạy, và còn gửi báo cáo qua email mỗi tuần một lần. Khôi phục toàn bộ có lẽ sẽ hơi đau đớn, nhưng vẫn tốt hơn là không có bản sao lưu nào.
Tôi đã tạo một shell script tương đối đơn giản để sửa việc đó.
https://github.com/torstenvl/tmutils
Nó vẫn còn khá beta nên nếu dùng thì phải cẩn thận. Các thay đổi metadata quan trọng đều có bước xác nhận, và script
dirdedupemặc định chạy ở chế độ test. Muốn nó thực sự làm gì đó thì phải dùng cờ--execute.CCC rất tuyệt, nhưng nó không sao lưu gần như theo thời gian thực và cũng không quản lý phiên bản. Nó có lẽ đã không thể cứu tôi như chiếc Time Machine “tích hợp” trong khe SD đã làm vào thứ Sáu tuần trước khi tôi đang di chuyển.
Điều gây chú ý là tác giả đã có được 16GB dung lượng lưu trữ với giá 25 USD, rồi chi thêm 70 USD để nâng lên 2TB
Với người dùng GNU/Linux, dù chắc chắn nó cũng sẽ hoạt động tốt với máy khách Microsoft và Apple, nhưng một tổ hợp hay là dùng Syncthing cho các mini server cục bộ và từ xa, rồi chỉ chạy BorgBackup ở phía máy chủ
Syncthing cung cấp đồng bộ gần như tức thì, còn BorgBackup cung cấp lưu trữ định kỳ theo chu kỳ và chính sách lưu giữ mong muốn
Để cách ly, mỗi thành viên trong gia đình có một VM nhỏ riêng, và họ được dặn hãy đặt những thứ thật sự quan trọng vào
~/work/hoặc~/private/Điều thú vị là APU hỗ trợ AES-NI và còn có một bộ tăng tốc mã hóa nhỏ cho SHA. Điều này tương phản với việc Raspberry Pi đã không chi thêm 1 USD cho Armv8 Cryptography Extensions
Với cùng mức điện năng nhàn rỗi 6.5W nhưng số lõi gấp đôi, tôi khuyên dùng t620 hơn t520
Nếu 2 lõi là đủ thì Fujitsu Futro s520 cũng tốt
https://heap.ovh/tag/thin-client.html
Tôi không thật sự chắc việc dùng AFP qua Netatalk có đúng hay không. Theo tôi biết thì Time Machine “gốc” hiện nay ưu tiên CIFS/Samba hơn trên mạng
“Nếu có thể chọn giữa SMB và AFP, hãy dùng SMB cho đĩa sao lưu ngoài”
https://support.apple.com/guide/mac-help/types-of-disks-you-...
Cách làm kiểu “Đừng lo. Tôi cũng dùng BackBlaze cho sao lưu tự động bên ngoài, và mọi dự án đều được lưu trên GitHub cùng nhiều PC khác” là rất khôn ngoan
Trong 20 năm tôi đã gặp 7 lần hỏng ổ đĩa nghiêm trọng, trong đó 4 lần là khi dùng các bản sao lưu tự dựng. Vì lười và làm qua loa nên trong 2 lần tôi đã mất rất nhiều dữ liệu. Các giải pháp sao lưu tự dựng không hợp với tôi
Bài viết trông như được viết hôm nay, nhưng điều quan trọng là chiếc Mac trong bài đang chạy macOS 5 năm tuổi. Với kinh nghiệm từng vận hành Raspberry Pi theo cấu hình tương tự một thời gian, tôi nghĩ giờ đây đó không còn là ý hay nữa
Nếu dùng Time Machine ngày nay thì nên sao lưu vào volume APFS có snapshot. Nó nhanh và đáng tin cậy hơn rất nhiều so với đĩa HFS+. Tôi cũng không còn khuyên dùng nữa vì có vẻ macOS rồi sẽ ngừng hoàn toàn hỗ trợ tạo bản sao lưu HFS+ mới vào một lúc nào đó
Vấn đề là thực tế không tồn tại trình điều khiển APFS cho Linux ở mức có thể tin tưởng để phụ thuộc cho việc sao lưu. Vì vậy lựa chọn thực tế là có một máy Mac để xử lý việc này. Trong mạng của tôi, có một chiếc MacBook Pro cũ thuộc thế hệ cuối cùng trước Touch Bar được nối dây vào backbone. Nó đắt hơn, nhưng cứ tin rằng đây là cấu hình bạn mong muốn
Nhân tiện, nếu dùng Time Machine qua chia sẻ mạng, tôi khuyên nên có thêm một bản sao lưu “trường hợp xấu nhất” được làm mới định kỳ. Đĩa mạng rất tiện nên tốt cho sao lưu định kỳ và truy cập nhanh, nhưng đôi khi Time Machine có thể tự làm hỏng chính nó theo cách mà nó không thể tự sửa được
Một giải pháp Time Machine qua mạng giá rẻ khác là dùng Intel Mac Mini cũ. Cấu hình Intel i5 2.5GHz, RAM 8GB, SSD 256GB có giá khoảng 120 USD, và chỉ cần cấu hình để chia sẻ đĩa Time Machine qua mạng
Nó không chỉ là Time Machine “xịn” mà còn có thể tiếp tục sao lưu lên chiếc đĩa Time Machine cũ trước đây từng cắm trực tiếp. Không cần học gì mới
Bản sao lưu Time Machine chính của tôi, cho MBP của tôi và của vợ tôi, là sao lưu qua SMB lên ZFS RAIDZ2 trên NAS. Nó đã hoạt động khá tốt khoảng 2 năm nay
Vấn đề tôi gặp dường như liên quan đến việc quota đã đặt bị hết chỗ. Do các snapshot ZFS, cơ chế tự dọn dẹp của Time Machine đã không giải phóng dung lượng như mong đợi. May mắn là tôi có thể dùng ZFS rollback để tìm snapshot lành gần nhất, xóa thủ công các snapshot ZFS cũ để tạo chỗ trống, chạy xác minh Time Machine rồi tiếp tục sử dụng. Trước đó tôi cũng đã tự tạo thêm snapshot “xác nhận còn tốt”
Gần đây tôi phát hiện thiết lập ZFS refquota, và có vẻ nó giải quyết được quy trình rắc rối ở trên, giúp quota hoạt động theo cách Time Machine mong đợi. Tất nhiên vẫn dùng thêm không gian vì snapshot ZFS, nhưng dữ liệu Time Machine chỉ chiếm một phần nhỏ trong tổng dung lượng của cả mảng nên không sao
Vấn đề khác là chuyện nâng cấp kernel và lỗi dkms khi dùng ZFS trên Arch, nhưng từ khi chuyển sang NixOS thì đã ổn định. Sao lưu Time Machine qua Tailscale cũng khá tốt
Ngoài ra tôi còn có bản sao lưu Time Machine thứ hai trên một ổ USB gắn vào AirPort Extreme
Trên cùng NAS đó tôi cũng dùng restic cho sao lưu đa nền tảng, và NAS đó gửi snapshot ZFS của dữ liệu Time Machine và restic sang một máy chủ từ xa
Cuối cùng, tôi để một ổ USB trong két sắt, và cứ khoảng mỗi tháng lại lấy ra để chạy thủ công một bản sao lưu Time Machine cục bộ qua kết nối trực tiếp
Việc sao lưu mọi thứ là một phần trong lời thề hôn nhân của chúng tôi, vừa đùa vừa thật. Rất nhiều thứ phụ thuộc vào đó
Lý do chính tôi mở liên kết là để xem tác giả đã chọn mẫu thin client nào, và đúng lúc đó lại là HP T520 mà tôi đang có một chiếc
Tôi không thể nói gì về Time Machine, nhưng với phần cứng và Linux thì đây là một máy chủ ổn định hơn so với các máy tính bo mạch đơn tương tự như Raspberry Pi hay Odroid. Nó cũng không tiêu thụ điện nhiều hơn đáng kể, chỉ là kích thước lớn hơn thôi