- แม้ Time Capsule จะเลิกผลิตไปแล้ว ก็ยังสามารถติดตั้ง Linux บนอุปกรณ์ขนาดเล็กกินไฟต่ำเพื่อทำ อุปกรณ์สำรองข้อมูลแบบเปิดทิ้งไว้ตลอด สำหรับ macOS ได้เองในราคาประหยัด
- HP t520 ราคา 25 ดอลลาร์รวมค่าส่ง มาพร้อม AMD G-Series แบบดูอัลคอร์, RAM 4GB, M.2 SATA SSD 16GB, Ethernet 1Gbps และพอร์ต USB 3.0 ซึ่งเพียงพอสำหรับใช้เป็นเซิร์ฟเวอร์งานเดียว
- ที่เก็บข้อมูลเลือกได้ระหว่าง M.2 SATA SSD ภายในกับไดรฟ์ USB3 ภายนอก และถ้าใช้ 2TB 2280 M.2 SATA SSD จะคุมต้นทุนรวมได้ราว 94 ดอลลาร์
- ติดตั้ง
netatalk และ avahi-daemon บน Bodhi Linux เพื่อทำ Time Machine share แบบ AFP แต่หลังเผยแพร่มีการเพิ่มหมายเหตุว่า AFP deprecated แล้วและควรใช้ Samba
- แบ็กอัปเริ่มต้นขนาด 460GB เดิมประเมินว่าจะใช้เวลา 21 วันที่ความเร็ว 2Mbit/s แต่หลังปรับ Power Nap,
debug.lowpri_throttle_enabled=0 และย้ายไปไว้ใกล้ Wi‑Fi AP ก็เพิ่มเป็น 120Mbit/s และเหลือ 8 ชั่วโมง
แนวคิด ThinMachine สำหรับใช้แทน Time Capsule
- Apple Time Machine เป็นจุดเริ่มให้เปลี่ยนมาใช้ Mac ในปี 2007 และหลังจากนั้นก็ใช้การสำรองข้อมูลแบบไร้สายผ่าน Time Capsule
- Time Capsule เดิมทำงานมานานกว่า 10 ปีก่อนจะเสีย และ macOS ก็แสดงการแจ้งเตือนซ้ำ ๆ ว่าการสำรองข้อมูลล้าสมัย
- แม้ Apple จะเลิกผลิต Time Capsule ไปแล้ว แต่หากตั้งค่าเซิร์ฟเวอร์ Linux ก็ยังทำอุปกรณ์สำรองข้อมูลลักษณะใกล้เคียงกันได้เอง
- ถ้าเป็นอุปกรณ์เฉพาะทางที่ต้องเปิดตลอด ฮาร์ดแวร์ที่เหมาะคือเครื่องเล็ก กินไฟต่ำ และวางในตู้เก็บอุปกรณ์อินเทอร์เน็ตได้
- Raspberry Pi ก็ใช้ได้ แต่ช่วงนั้นหาซื้อยาก และราคาเกิน 80 ดอลลาร์ แถมต้องซื้อเคสกับแหล่งจ่ายไฟแยก ทำให้ไม่คุ้มเท่าไร
- ทางเลือกที่เลือกคือ เครื่อง thin client PC มือสอง และซื้อ HP t520 จาก eBay ในราคา 25 ดอลลาร์รวมค่าส่ง
ฮาร์ดแวร์และการใช้พลังงานของ HP t520
- สเปกพื้นฐานของ HP t520 ราคา 25 ดอลลาร์เพียงพอสำหรับใช้เป็นเซิร์ฟเวอร์สำรองข้อมูลแบบเรียบง่าย
- AMD G-Series GX-212JC CPU ดูอัลคอร์ 1.2GHz และ Radeon R2E
- 4GB DDR3-1600
- M.2 SATA SSD 16GB
- Ethernet 1Gbps
- USB 3.0 2 พอร์ต, USB 2.0 4 พอร์ต
- DisplayPort 2 พอร์ต, VGA 1 พอร์ต
- ขาตั้งแนวตั้ง
- อะแดปเตอร์ไฟ 18.5V และสาย
- ไม่มี Wi‑Fi แต่ตั้งใจจะวางไว้ข้างเราเตอร์ในตู้เก็บอุปกรณ์อินเทอร์เน็ตจึงไม่เป็นปัญหา และหากจำเป็นก็ใช้สล็อต mini PCIe ที่ว่างอยู่ได้
- ไม่ได้ลองเพิ่ม Wi‑Fi เอง จึงยังยืนยันไม่ได้ว่าใช้งานได้ 100%
- t520 ใช้ไฟ 6W ตอน idle และ 10W ในสถานการณ์อื่น
- หากคิดค่าไฟเฉลี่ยที่ 0.35 ดอลลาร์ต่อ kWh ค่าเปิดทิ้งไว้ตลอดที่ 6W จะอยู่ที่ราว 19 ดอลลาร์ต่อปี
- thin client รุ่นอื่นอย่าง HP t610 อาจกินไฟ idle เกิน 10W เพราะใช้ชิปเซ็ตรุ่นเก่า
- Raspberry Pi 4 วัดได้ประมาณ 4W
- ระบบปฏิบัติการเดิมคือ HP Thin Pro ซึ่งเป็นดิสโทรแบบคัสตอมที่อิงกับ Tiny Core Linux
- HP Thin Pro มีไคลเอนต์ Citrix และ VMWare มาให้
- เคยลอง Tiny Core Linux ต้นฉบับด้วย แต่จำนวนแพ็กเกจที่มีให้น้อยเกินไป
การเลือกที่เก็บข้อมูลสำรอง: SSD ภายในและ USB3 ภายนอก
- ความจุ SSD ภายในที่ t520 รองรับอย่างเป็นทางการคือ 64GB แต่เป็นสเปกจากยุคที่ยังไม่มี M.2 SSD ความจุสูงกว่านี้
- สล็อต M.2 ภายในรองรับฟอร์มแฟกเตอร์ 2242 และ 2260 ส่วน SSD แบบ 2280 จะชนกับลำโพงตามค่าเริ่มต้น
- สามารถถอดลำโพงออกได้โดยยกเมนบอร์ดขึ้นแล้วคลายน็อต 2 ตัว
- ก่อนติดตั้ง 2280 SSD ต้องใช้เทปปิดแผ่นทองแดงและลายวงจรที่เปิดอยู่ด้านหลัง SSD
- แม้จะไม่มีน็อตยึดทำให้ SSD อาจหลุดจากซ็อกเก็ตได้ แต่ในการใช้งานจริงก็ไม่ได้มองว่าเป็นความเสี่ยงใหญ่
- สล็อตภายในของ t520 รองรับเฉพาะ M.2 SATA SSD
- SSD ความจุสูงส่วนใหญ่มักเป็น NVMe แต่สล็อตนี้ไม่ใช่สำหรับ PCIe/NVMe
- HP เลือกคอนเน็กเตอร์ผิด ทำให้ NVMe SSD สามารถเสียบเข้าไปได้ทางกายภาพ
- หากเสียบ NVMe SSD อาจทำให้ SSD, เมนบอร์ด หรือทั้งคู่เสียหายได้
- ตอนเลือกสตอเรจภายใน มีความต่างด้านราคาและฟอร์มแฟกเตอร์มาก
- 2TB 2260 M.2 SATA SSD ราคา 149 ดอลลาร์บน Amazon
- 2TB 2280 M.2 SATA SSD มีราคาเริ่มต้นที่ 69 ดอลลาร์
- 4TB 2280 SATA SSD กระโดดไปที่ 260 ดอลลาร์
- 2TB 2280 M.2 SATA SSD ที่เลือกใช้งานได้ปกติ และทำให้ต้นทุนรวมของ ThinMachine ขนาด 2TB อยู่ที่ 94 ดอลลาร์
- ไดรฟ์ USB3 ภายนอกเป็นอีกทางเลือกที่ติดตั้งง่ายกว่า
- 4TB SSD แบบ 2.5 นิ้วเริ่มที่ 150 ดอลลาร์ และสามารถใช้ความจุใหญ่กว่านี้ได้
- ถอดไดรฟ์ไปเก็บหรือไปต่อกับพีซีเครื่องอื่นได้ง่าย
- ไม่ต้องเปิดฝา t520
- ข้อเสียคือต้องมีเคส USB3 และหน้าตาไม่เรียบร้อยนัก
การติดตั้ง Bodhi Linux และการแบ่งพาร์ทิชัน
- หลังมองหาดิสโทรที่อิง Ubuntu และมีอิมเมจติดตั้งขนาดเล็ก จึงเลือก Bodhi Linux
- รุ่น HWE มีขนาด 837MB ใหญ่กว่ารุ่นมาตรฐาน 5MB และรองรับฮาร์ดแวร์ใหม่กว่า
- การดาวน์โหลด Ubuntu ISO ช้า แต่ Bodhi Linux ISO ดาวน์โหลดได้เร็ว
- ขั้นตอนติดตั้งเป็นแบบบูตผ่าน USB ตามปกติ
- เตรียม USB stick ขนาด 1GB ขึ้นไป
- ใช้ Balena Etcher เขียน ISO ลง USB
- เสียบ USB เข้ากับ t520 แล้วบูต
- ทำตามโปรแกรมติดตั้งเพื่อลง Bodhi Linux ใน SSD ของ t520
- พาร์ทิชันของ SSD ภายในแยกระหว่าง OS กับข้อมูลสำรอง
/dev/sda1: efi, 1GB, เป็นพาร์ทิชันบูตและต้องเป็นพาร์ทิชันแรก/dev/sda2: ext4, 16GB, สำหรับติดตั้ง Bodhi Linux/dev/sda3: ext4, พื้นที่ที่เหลือทั้งหมด, เป็นพาร์ทิชันข้อมูลสำรอง
- จุดเมานต์ก็แยกชัดเจนเช่นกัน
/dev/sda2 เมานต์ที่ root directory //dev/sda3 เมานต์ที่ /mnt/timemachine
- หลังติดตั้ง Bodhi Linux ใช้พื้นที่บน SSD ไปเพียงเล็กน้อยเกิน 5GB ดังนั้นจัดให้ 16GB ก็ยังมีพื้นที่พอสำหรับติดตั้งเครื่องมือเพิ่ม
บัญชีเซิร์ฟเวอร์ Time Machine และการตั้งค่า AFP
- เริ่มจากอัปเดตแพ็กเกจให้เป็นเวอร์ชันล่าสุด
sudo apt update && sudo apt dist-upgrade
- ติดตั้งแพ็กเกจที่จำเป็นต่อการทำงานของ Time Machine
sudo apt install procinfo netatalk avahi-daemon
- Avahi เป็นโอเพนซอร์สอิมพลีเมนเทชันของระบบเครือข่ายแบบ zero-configuration เช่นเดียวกับ Apple Bonjour ทำให้ Mac มองเห็นเซิร์ฟเวอร์ thinmachine บนเครือข่ายได้
- Netatalk เป็นโอเพนซอร์สอิมพลีเมนเทชันของ Apple Filing Protocol และมีการรองรับ Apple Time Machine ด้วย
- สร้างบัญชี
timemachine สำหรับใช้งานโดยเฉพาะ
- บัญชีนี้ไม่มีสิทธิ์
root หรือ sudo และไม่สร้างไดเรกทอรี /home
- ตอนเชื่อมต่อ Mac เข้ากับเซิร์ฟเวอร์ จะใช้ชื่อผู้ใช้นี้และรหัสผ่านนี้
- รหัสผ่านนี้ไม่ใช่รหัสผ่านสำหรับเข้ารหัสข้อมูลสำรอง
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
- แก้ไข
/etc/netatalk/afp.conf เพื่อตั้งค่า Time Machine share
vol size limit ใช้จำกัดขนาดดิสก์ที่ Time Machine จะใช้ได้ โดยระบุเป็นหน่วย MB- ในกรณีนี้ใช้ทั้งไดรฟ์สำหรับ Time Machine จึงไม่ได้กำหนดเพดานความจุ
hostname ไม่จำเป็นต้องตรงกับ Unix hostname แต่จะเป็นชื่อที่แสดงบนเครือข่าย Bonjour
;
; Netatalk 3.x configuration file
;
[Global]
hostname = thinmachine
[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
- เปิดใช้และเริ่มเดมอนที่จำเป็น
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
- เปิดพอร์ตที่จำเป็นบนไฟร์วอลล์แล้วรีสตาร์ต Netatalk
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
- การตั้งค่านี้เป็นแบบ AFP-based และหลังเผยแพร่มีการเพิ่มหมายเหตุว่า AFP ถูก deprecated แล้วและควรใช้ Samba
การกู้คืนพลังงานและการเชื่อมต่อกับ Mac
- อุปกรณ์สำรองข้อมูลควรเปิดเองอัตโนมัติหลังไฟดับแล้วไฟกลับมา จึงต้องเปลี่ยนค่าที่ BIOS
- กด F10 ระหว่างเริ่มบูตเพื่อเข้า BIOS settings
- ไปที่
Advanced → Power-On Options
- ตั้งค่า
After Power Loss เป็น On
- ในการตั้งค่า Time Machine บน Mac เมื่อกด
Select Disk จะเห็น ThinMachine เป็นตัวเลือก
- การเข้ารหัสข้อมูลสำรองทำบน Mac และตัว thin client ไม่ได้เกี่ยวข้องกับการเข้ารหัสหรือถอดรหัส
- หากทำรหัสผ่านสำรองหาย จะไม่มีวิธีกู้ข้อมูลกลับมาได้
- การสำรองครั้งแรกอาจใช้เวลานาน
การปรับปรุงความเร็วของแบ็กอัปครั้งแรก
- ใน MacBook มีข้อมูลอยู่ 460GB และการสำรองของ Time Machine เป็นแบบ atomic หมายความว่าหากไม่เสร็จสมบูรณ์จะต้องเริ่มใหม่ทั้งหมด
- ความเร็วแบ็กอัปเริ่มต้นอยู่ที่ราว 2Mbit/s ซึ่งหมายถึงจะใช้เวลาประมาณ 21 วันสำหรับแบ็กอัปทั้งหมด
- ระหว่างนั้นหากปิดแล้วเปิดเซิร์ฟเวอร์ใหม่ หรือนำโน้ตบุ๊กออกนอกระยะ Wi‑Fi ก็ต้องเริ่มแบ็กอัปใหม่ตั้งแต่ต้น
- เปิดใช้งาน Power Nap แม้ขณะใช้แบตเตอรี่
- เมื่อเปิด Power Nap การสำรองข้อมูล Time Machine จะดำเนินต่อได้แม้ปิดฝาโน้ตบุ๊กหรือใช้งานด้วยแบตเตอรี่
- ถ้าปิด Power Nap แบ็กอัปจะหยุดและเริ่มใหม่
- ระหว่างแบ็กอัปเต็มครั้งแรก ให้ปิดการจำกัดโปรเซสเบื้องหลัง
sudo sysctl debug.lowpri_throttle_enabled=0
- การตั้งค่านี้ทำให้ความเร็วแบ็กอัปเพิ่มจาก 2Mbit/s เป็น 20Mbit/s
- หลังสำรองข้อมูลครั้งแรกเสร็จ ควรเปิดการจำกัดกลับมาอีกครั้ง
sudo sysctl debug.lowpri_throttle_enabled=1
- เมื่อนำโน้ตบุ๊กไปไว้ใกล้ access point ของเครือข่าย mesh Wi‑Fi ของ Eero ความเร็วเพิ่มจาก 20Mbit/s เป็น 120Mbit/s
- จากการปรับลำดับความสำคัญและวางใกล้ AP ทำให้เวลาสำรองข้อมูล 460GB ลดจาก 21 วันเหลือ 8 ชั่วโมง
ผลการใช้งานและความเป็นไปได้เพิ่มเติม
- หลังใช้งานไปไม่กี่วัน คำเตือนเรื่องการสำรองข้อมูลเก่าบน MacBook ก็หายไป และการสำรองข้อมูลทำงานเบื้องหลังได้ตามปกติ
- สามารถต่อไดรฟ์เพิ่มเข้ากับ t520 แล้วขยายเป็น NAS ได้ด้วย แต่ยังไม่รู้สึกว่าจำเป็น
- หากกังวลเรื่องไดรฟ์ภายในเสีย ก็สามารถทำสำเนาทั้งหมดเป็นระยะลงไดรฟ์ภายนอกได้เช่นกัน
- มีการใช้ Backblaze เป็นบริการสำรองข้อมูลนอกสถานที่อยู่แล้ว จึงมองว่ามีความซ้ำซ้อนเพียงพอ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ไม่เชื่อถือ Time Machine อีกต่อไปแล้ว เมื่อหลายปีก่อนผมเขียนเชลล์สคริปต์ที่ทำให้การตั้งค่าทั้งระบบแทบทั้งหมดเป็นอัตโนมัติได้โดยใช้
brewเป็นต้น และเป็นครั้งคราวก็ล้างระบบทั้งหมดแล้วกู้คืนด้วยสคริปต์นั้นสำหรับการสำรองข้อมูลใช้ restic ข้อดีมากคือสามารถอ่านแบ็กอัปได้แม้ไม่มีอุปกรณ์ macOS ตอนที่เครื่อง macOS เครื่องเดียวมีปัญหาฮาร์ดแวร์ แบ็กอัปจาก Time Machine แทบไม่มีประโยชน์เลยจนกว่าจะหา Mac เครื่องใหม่ได้
อาจไม่ใช่วิธีที่เหมาะกับทุกคน แต่ Time Machine ทำแบ็กอัปพังเกิน 5 ครั้งแล้ว และยังช้ากว่า restic มาก จนถึงมี macOS รุ่นใหม่ออกมาก็ไม่คิดจะลองอีก
เป็นแค่ผู้ใช้ที่ใช้งานมันได้ดีมา 9 ปี ไม่ได้มีส่วนเกี่ยวข้องใดๆ
[1] https://www.arqbackup.com
ตอนนี้ใช้ Carbon Copy Cloner, Syncthing และ Arq ทำให้แบ็กอัปของครอบครัวเร็วขึ้น ลื่นไหลกว่าเดิม และจัดการง่ายขึ้นมาก
แต่บน macOS มีบัญชีผู้ใช้ 2 บัญชี คือของตัวเองกับของคู่สมรส และทำให้ Restic เข้าถึงข้อมูลของอีกบัญชีไม่ได้ ผมเป็นแอดมิน รันด้วย root และให้สิทธิ์ “การเข้าถึงดิสก์ทั้งหมด” แล้วก็ยังไม่ได้ อยากได้คำแนะนำ
ถึงจะใช้
brewกับbrew caskก็ยังมีแอป GUI จำนวนมากที่ต้องติดตั้งเอง และการตั้งค่าของแต่ละอย่างก็กระจายอยู่หลายที่ ถ้ารวมถึง CLI หรือเครื่องมือเบื้องหลังที่ติดตั้งเอง รวมถึงการตั้งค่าระบบด้วย ก็ยังไม่รู้ว่าจะทำให้การกู้คืนทั้งหมดนี้เป็นอัตโนมัติอย่างสมเหตุสมผลได้อย่างไรโดยไม่มีแบ็กอัปแบบ Time Machine หรือพูดอีกอย่างคือไม่มีดิสก์อิมเมจแล้วก็อยากรู้ว่าบนเวอร์ชัน APFS ก็เจอความเสียหายแบบเดียวกันด้วยหรือเปล่า
ผมรันทั้ง Pi-hole และ Time Machine บน Raspberry Pi และมันอาจเป็นของที่คุ้มค่าที่สุดในบรรดาสินค้าเทคทั้งหมดที่เคยซื้อมา ทำตาม https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-...
แพงกว่า ต้องมีเคสและแหล่งจ่ายไฟแยกต่างหาก และถ้าไม่มีเคส USB3 เพิ่มก็ใช้ M.2 SSD ไม่ได้ อีกทั้งยังมีประวัติเรื่องแฟลชการ์ดเสียหาย และการใช้ไฟตอนว่างก็ต่ำกว่าเพียงเล็กน้อย
ผมยกให้ลูกสาวที่ไปมหาวิทยาลัยเอาไปใช้ แต่ก็สงสัยมากว่าเธอได้ใช้จริงหรือเปล่า และก่อนเห็นโพสต์นี้ก็ไม่เคยนึกจะถามเลย
ถ้าอยากรักษาสุขภาพจิต แนะนำให้เลิกใช้ Time Machine แล้วไปใช้ Carbon Copy Cloner [0] ดีกว่า มันทำงานได้จริง ทำงานต่อเนื่อง เอกสารสำหรับสถานการณ์แบ็กอัปและกู้คืนที่เป็นไปได้ก็ดีเยี่ยม และแสดงอย่างโปร่งใสว่ากำลังทำอะไรอยู่
Time Machine มักจะใช้ได้ดีอยู่พักหนึ่งแล้วจู่ ๆ ก็ใช้ไม่ได้ แถมจะไม่บอกด้วยว่าแบ็กอัปพัง จนกว่าจะลองกู้คืนก่อน ข้อผิดพลาดก็เข้าใจยาก ไม่มีซัพพอร์ต ฟอรัมก็ไม่ช่วยอะไร และแบ็กอัปที่พังแล้วก็ซ่อมไม่ได้ Time Machine ใช้แนวทางแบบ “เชิญผู้ใช้ไปรับกรรมเอาเอง” โดยไม่ให้ข้อมูลอะไรเลยว่ามันกำลังทำอะไร ไม่ได้ทำอะไร หรือกำลังพยายามจะทำอะไร
ถ้าข้อมูลของคุณมีค่าพอจะต้องแบ็กอัป ก็ไม่ควรใช้ Time Machine
[0] https://bombich.com
แม้แต่ iCloud ก็ได้ยินแต่คำตอบเดิม ๆ ทุกที่ว่า “ข้อมูลกำลังซิงก์อยู่”, “ลองปิดแล้วเปิดใหม่”, “ลองรีสตาร์ต” เท่านั้น เวลาเห็น Apple Support พูดอย่างมั่นใจว่าให้รีเซ็ต iOS หรือไม่ก็ติดตั้ง macOS ใหม่ทั้งระบบเพียงเพราะปัญหาซิงก์เล็กน้อย ก็ให้ความรู้สึกเหมือนกำลังคุยกับบอตซาดิสม์แบบคาฟคา
นี่คือ playbook ของ Apple ต่อให้วิจารณ์ในโซเชียลมีเดียแบบเปิดเผยก็ไม่ช่วย อีเมลก็ไม่มีคำตอบ คำขอจากลูกค้าก็ถูกปิดกั้น บางครั้งถึงขั้นรู้สึกว่าผมน่าจะเป็นฝ่ายได้รับเงินเพื่อใช้ผลิตภัณฑ์ Apple เสียมากกว่า
ตอนที่ผู้จัดการคนเก่าบอกว่าถ้าได้ Mac ไม่ว่าจะใช้ส่วนตัวหรือใช้ทำงาน สิ่งแรกที่เขาทำคือ ลง Linux ก่อน พนักงานใหม่ ๆ มองเขาเหมือนพวกคลั่ง GNU/FOSS แปลก ๆ เขาแค่หัวเราะแล้วบอกว่าเดี๋ยวเวลาผ่านไปก็จะเข้าใจ และตอนนี้ผมก็เข้าใจแล้วว่าระบบนิเวศของ Apple ทั้งไร้อำนาจและเป็นปฏิปักษ์แค่ไหน พอทนกับกำแพงและข้อจำกัดน่าหงุดหงิดเหล่านี้ไปนาน ๆ มันจะกลายเป็นสภาพตัวประกันที่ทำให้รู้สึกว่านี่คือทางเดียว
ณ จุดนี้ การบอกว่า Time Machine หรือฟีเจอร์ของ Apple ที่เกี่ยวกับความถูกต้องสมบูรณ์และความน่าเชื่อถือของข้อมูลนั้น “ใช้งานได้ดี” หรือ “ดีพอแล้ว” หรือการพึ่งพาอะไรอย่าง iCloud สำหรับการแบ็กอัปและความสมบูรณ์ของข้อมูล ผมมองว่าแทบจะเป็นการทำลายตัวเอง
กำลังรอวันที่บน iOS จะเข้าถึงไฟล์ภายใต้สิทธิ์อนุญาตแบบชัดเจนได้ง่ายขึ้น หรือ Android จะห่วยน้อยลง สุดท้ายก็ต้องบังคับให้แพลตฟอร์มคู่อำนาจผูกขาดอันทรงเกียรตินี้เปิดตัวเองออกมา เพราะพวกเขาจะไม่ทำเองแน่
Time Machine ฟรี และสำหรับคนส่วนใหญ่ การแบ็กอัปแบบโลคัลหรือผ่านเครือข่ายโลคัลก็ “ดีพอแล้ว” ส่วนการแบ็กอัประยะไกลก็มี BorgBase, Vorta ซึ่งเป็นแอป GUI ของ borg ที่แย่มาก และ Backblaze ที่พอรับมือได้เป็นตัวเลือก
อีกอย่างดูเหมือนว่า CCC จะไม่มีแบ็กอัปแบบ write-only ที่ไม่เปลี่ยนแปลงได้จากฝั่งไคลเอนต์หลังสร้างเสร็จเหมือน Borg และในรายการฟีเจอร์ก็ไม่เห็นการเข้ารหัสหรือการลบข้อมูลซ้ำ https://bombich.com/features
ตอนนี้ผมใช้ Time Machine แบ็กอัปทั้งไปยังเซิร์ฟเวอร์ TrueNAS และดิสก์โลคัล เวลาที่นึกได้ว่าเสียบมันเข้าไป ทั้งสองอย่างเลย ส่วน home directory แบ็กอัปไปที่ B2 ด้วย Arq
สำหรับคนในครอบครัว ผมให้ใช้ Backblaze มันเป็นวิธีเดียวจริง ๆ ที่ตั้งค่าแล้วลืมได้เลย คนในครอบครัวมักลืมเสียบไดรฟ์ Time Machine แบบโลคัลอยู่เสมอ และถ้าตั้ง Time Machine กับไดรฟ์เครือข่าย มันก็มักเพี้ยนทุก ๆ สองสามเดือนจนแบ็กอัปไม่ได้ แล้วพวกเขาก็แค่เมินข้อความของ Time Machine ไป
Backblaze แทบจะเรียกได้ว่าใช้งานได้เองอยู่แล้ว และยังส่งรายงานทางอีเมลทุกสัปดาห์ด้วย การกู้คืนทั้งระบบคงจะเจ็บปวดหน่อย แต่ก็ยังดีกว่าไม่มีแบ็กอัปเลย
ผมเลยทำเชลล์สคริปต์ที่ค่อนข้างเรียบง่ายไว้เพื่อแก้ปัญหานี้
https://github.com/torstenvl/tmutils
ตอนนี้ยังค่อนข้างเป็นเบตาอยู่ ถ้าจะใช้ต้องระวัง มีขั้นตอนยืนยันสำหรับการเปลี่ยน metadata สำคัญ ๆ และสคริปต์
dirdedupeจะรันในโหมดทดสอบเป็นค่าเริ่มต้น ถ้าจะให้มันลงมือทำอะไรจริง ๆ ต้องใช้แฟลก--executeCCC ยอดเยี่ยมก็จริง แต่ไม่ได้แบ็กอัปแทบจะเรียลไทม์ และไม่มีการทำ versioning ด้วย มันคงช่วยผมไม่ได้แบบที่ Time Machine แบบ “ฝังในเครื่อง” ผ่านช่อง SD ช่วยไว้เมื่อวันศุกร์ที่แล้วตอนกำลังเดินทาง
สิ่งที่สะดุดตาคือผู้เขียนได้พื้นที่เก็บข้อมูล 16GB มาในราคา 25 ดอลลาร์ และจ่ายเพิ่มอีก 70 ดอลลาร์เพื่ออัปเกรดเป็น 2TB
สำหรับผู้ใช้ GNU/Linux แนวทางที่ดีคือใช้ Syncthing บนมินิเซิร์ฟเวอร์ทั้งในเครื่องและระยะไกล แล้วให้ฝั่งเซิร์ฟเวอร์รัน BorgBackup เท่านั้น ซึ่งแน่นอนว่าน่าจะทำงานได้ดีกับไคลเอนต์ของ Microsoft และ Apple ด้วย
Syncthing ให้การซิงก์แทบจะทันที ส่วน BorgBackup ให้การทำ archive ตามรอบเวลาและนโยบายการเก็บรักษาที่ต้องการ
เพื่อการแยกส่วนจึงมี VM เล็ก ๆ แยกให้สมาชิกครอบครัวแต่ละคน และบอกให้เอาของที่สำคัญจริง ๆ ไปไว้ใน
~/work/หรือ~/private/ที่อยู่ภายใต้การจัดการที่น่าสนใจคือ APU รองรับ AES-NI และยังมีตัวเร่งการเข้ารหัสขนาดเล็กสำหรับ SHA ด้วย ซึ่งตัดกับ Raspberry Pi ที่ไม่ยอมเพิ่มต้นทุนอีก 1 ดอลลาร์เพื่อใส่ Armv8 Cryptography Extensions
ด้วยการกินไฟขณะ idle เท่ากันที่ 6.5W แต่มีจำนวนคอร์เป็นสองเท่า จึงแนะนำ t620 มากกว่า t520
ถ้าสองคอร์ก็เพียงพอ Fujitsu Futro s520 ก็เป็นตัวเลือกที่ดี
https://heap.ovh/tag/thin-client.html
ไม่แน่ใจจริง ๆ ว่าการใช้ AFP ผ่าน Netatalk นั้นใช่ทางที่ถูกต้องหรือไม่ เท่าที่เข้าใจ Time Machine แบบ “native” ปัจจุบันดูจะชอบ CIFS/Samba มากกว่าบนเครือข่าย
“ถ้าเลือกได้ระหว่าง SMB กับ AFP ให้ใช้ SMB สำหรับดิสก์สำรองข้อมูลภายนอก”
https://support.apple.com/guide/mac-help/types-of-disks-you-...
วิธีคิดแบบ “ไม่ต้องห่วงนะ ฉันใช้ BackBlaze สำหรับแบ็กอัปภายนอกอัตโนมัติด้วย และทุกโปรเจกต์ก็เก็บไว้ทั้งบน GitHub และหลาย ๆ PC” ถือว่าฉลาด
ตลอด 20 ปีที่ผ่านมา ฉันเจอไดรฟ์พังแบบหนัก ๆ มา 7 ครั้ง และ 4 ครั้งในนั้นเกิดตอนที่ใช้แบ็กอัปแบบทำเอง สองครั้งทำข้อมูลหายไปเยอะเพราะขี้เกียจและทำแบบลวก ๆ โซลูชันแบ็กอัปที่ทำเองจึงไม่เหมาะกับฉัน
แม้บทความจะดูเหมือนเขียนวันนี้ แต่ประเด็นสำคัญคือ Mac ในบทความรัน macOS ที่เก่า 5 ปี จากประสบการณ์ที่เคยรัน Raspberry Pi ด้วยการตั้งค่าใกล้เคียงกันอยู่พักหนึ่ง ฉันมองว่าตอนนี้มันไม่ใช่ความคิดที่ดีแล้ว
ถ้าจะใช้ Time Machine ในยุคนี้ ก็ควรแบ็กอัปลง โวลุม APFS ที่มีสแนปช็อต มันทั้งเร็วและเชื่อถือได้มากกว่าดิสก์ HFS+ มาก และดูเหมือนว่าในสักวันหนึ่ง macOS อาจเลิกสนับสนุนการสร้างแบ็กอัป HFS+ ใหม่ไปเลย จึงไม่แนะนำอีกต่อไป
ปัญหาคือแทบไม่มีไดรเวอร์ APFS สำหรับ Linux ที่เชื่อถือได้มากพอให้ฝากชีวิตงานแบ็กอัปไว้ได้ ดังนั้นทางเลือกที่ใช้งานได้จริงคือมี Mac ไว้จัดการเรื่องนี้ ในเครือข่ายของฉันมี MacBook Pro เก่ารุ่นท้าย ๆ ก่อนยุค Touch Bar ต่อสายเข้ากับแบ็กโบนอยู่ แม้จะแพง แต่เชื่อได้ว่านี่คือการตั้งค่าที่คุณต้องการ
อนึ่ง ถ้าใช้ Time Machine ผ่าน network share ขอแนะนำให้มีแบ็กอัปอีกชุดสำหรับกรณีเลวร้ายที่สุดที่คอยอัปเดตเป็นระยะ ๆ ด้วย ดิสก์เครือข่ายนั้นสะดวก เหมาะกับการแบ็กอัปประจำและการเข้าถึงที่รวดเร็ว แต่บางครั้ง Time Machine ก็สามารถทำตัวเองเสียหายในแบบที่ซ่อมเองไม่ได้
ทางออกแบบประหยัดอีกอย่างสำหรับ Time Machine ผ่านเครือข่ายคือใช้ Intel Mac Mini มือสอง สเปก 2.5GHz Intel i5, RAM 8GB, SSD 256GB ราคาประมาณ 120 ดอลลาร์ แล้วตั้งค่าให้แชร์ดิสก์ Time Machine ออกทางเครือข่าย
นอกจากจะเป็น Time Machine แบบ “ของแท้” แล้ว ยังสามารถต่อยอดแบ็กอัปจากดิสก์ Time Machine เดิมที่เคยเสียบใช้งานตรง ๆ ได้ด้วย ไม่ต้องเรียนรู้อะไรใหม่
แบ็กอัป Time Machine หลักของฉันสำหรับ MBP ของฉันและภรรยา ใช้วิธีแบ็กอัปผ่าน SMB ไปยัง ZFS RAIDZ2 บน NAS ซึ่งทำงานได้ค่อนข้างดีมาเกือบ 2 ปีแล้ว
ปัญหาที่เจอเหมือนจะเกี่ยวกับพื้นที่ไม่พอภายใต้โควต้าที่ตั้งไว้ เพราะ ZFS snapshots ทำให้กลไกล้างข้อมูลอัตโนมัติของ Time Machine ไม่สามารถคืนพื้นที่ได้ตามที่คาดหวัง โชคดีที่ฉันย้อนกลับไปหา snapshot ล่าสุดที่ยังปกติได้ด้วย ZFS rollback จากนั้นลบ ZFS snapshots เก่าแบบ manual เพื่อคืนพื้นที่ รันการตรวจสอบของ Time Machine แล้วก็ใช้งานต่อได้ ก่อนหน้านั้นก็สร้าง snapshot แบบ “ยืนยันว่าปกติ” ไว้ด้วยตนเองแล้ว
ไม่นานมานี้ฉันเพิ่งเจอการตั้งค่า ZFS refquota และดูเหมือนว่ามันจะแก้ขั้นตอนยุ่งยากข้างต้นได้ ทำให้โควต้าทำงานในแบบที่ Time Machine คาดหวัง แน่นอนว่า ZFS snapshots ยังใช้พื้นที่เพิ่มอยู่ แต่ข้อมูล Time Machine ก็กินเพียงส่วนน้อยของพื้นที่รวมทั้งอาร์เรย์ จึงไม่เป็นไร
อีกปัญหาหนึ่งคือเรื่อง kernel upgrade กับปัญหา dkms ตอนใช้ ZFS บน Arch แต่หลังจากย้ายไป NixOS ก็เสถียรดี การแบ็กอัป Time Machine ผ่าน Tailscale ก็ค่อนข้างดีเช่นกัน
แยกกันอีกชุดหนึ่ง ฉันมีแบ็กอัป Time Machine ชุดที่สองอยู่บนไดรฟ์ USB ที่ต่อกับ AirPort Extreme
บน NAS ลูกเดียวกันนั้นยังใช้ restic สำหรับแบ็กอัปข้ามแพลตฟอร์มด้วย และ NAS เครื่องนั้นก็ส่ง ZFS snapshots ของข้อมูล Time Machine และ restic ไปยังเซิร์ฟเวอร์ระยะไกล
สุดท้าย ฉันมีไดรฟ์ USB อีกลูกเก็บไว้ในตู้เซฟ และประมาณเดือนละครั้งจะหยิบออกมารันแบ็กอัป Time Machine แบบเชื่อมต่อในเครื่องด้วยตนเอง
การสำรองข้อมูลทุกอย่างไว้เป็นส่วนหนึ่งของคำสาบานตอนแต่งงานของเราแบบพูดเล่นปนจริง เรื่องนี้มีเดิมพันสูงมาก
เหตุผลหลักที่เปิดลิงก์นี้ก็เพื่อจะดูว่าผู้เขียนเลือก รุ่น thin client อะไร และบังเอิญว่าเป็น HP T520 รุ่นเดียวกับที่ฉันมีอยู่เครื่องหนึ่ง
สำหรับ Time Machine ฉันคงพูดอะไรไม่ได้มาก แต่ในแง่การจับคู่ฮาร์ดแวร์กับ Linux มันเป็นเซิร์ฟเวอร์ที่เสถียรกว่า single-board computer อย่าง Raspberry Pi หรือ Odroid ที่คล้ายกัน แทบไม่ได้กินไฟเพิ่มขึ้นมากนัก มีแค่ขนาดใหญ่กว่า