Apple ทำ Time Machine พังอีกครั้งในอัปเดต Tahoe

 (taoofmac.com)
2 คะแนน โดย GN⁺ 2026-02-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังอัปเดต macOS Tahoe พบปัญหาที่ข้อมูลสำรอง Time Machine หยุดทำงานเงียบ ๆ บน Mac สองเครื่อง
  • ในสภาพแวดล้อมที่ สำรองข้อมูลไปยัง Synology NAS ผ่าน SMB การสำรองหยุดไปนานราวสองเดือนโดยไม่มีข้อความผิดพลาด
  • สาเหตุคือ Apple เปลี่ยนค่าตั้งต้นของ SMB ฝั่งเดียว ทำให้แก้ชั่วคราวได้ด้วยการแก้ไฟล์ nsmb.conf
  • ระยะยาวกำลังพิจารณาเปลี่ยนไปใช้ เซิร์ฟเวอร์ Time Machine บน Proxmox + Docker หรือ Borg Backup
  • มีการแสดง ความไม่พอใจและข้อเรียกร้องให้ปรับปรุง ต่อกรณีที่ Apple ทำให้ Time Machine พังซ้ำ ๆ และไม่ประกาศการเปลี่ยนแปลงที่เกี่ยวข้อง

ปัญหาการสำรองข้อมูล Time Machine หยุดทำงาน

  • หลัง macOS เวอร์ชัน Tahoe เป็นต้นมา Time Machine ไม่ทำงานบน Mac สองเครื่อง

    • ใช้ Synology NAS เป็น ปลายทางแชร์ผ่าน SMB และใช้งานได้โดยไม่มีปัญหามาหลายปี
    • เพิ่งพบว่าการสำรองหยุดไปแล้วสองเดือนระหว่างพยายามกู้คืนข้อมูล Obsidian
    • มันหยุดทำงานแบบเงียบ ๆ โดยไม่มีข้อความผิดพลาดหรือการแจ้งเตือน โดยแล็ปท็อปสำรองครั้งล่าสุดในเดือนธันวาคม ส่วนเดสก์ท็อปยังมีการสำรองเสริมลงไดรฟ์ภายนอก

  • สาเหตุของปัญหาคือ Apple เปลี่ยนค่าตั้งต้นของ SMB

    • เปลี่ยนจาก signing_required=no ไปเป็น การตั้งค่าความปลอดภัยที่เข้มงวดขึ้น
    • อุปกรณ์ NAS บางรุ่นรับมือกับการเปลี่ยนแปลงนี้ไม่ได้ ทำให้การสำรองล้มเหลว
    • Apple ไม่ได้แจ้งการเปลี่ยนแปลงนี้อย่างเป็นทางการ

วิธีแก้ชั่วคราว

  • อ้างอิง Zahorone Gist บน GitHub แล้วแก้ไขไฟล์ /etc/nsmb.conf

    • เพิ่มรายการต่อไปนี้ในไฟล์: 
      [default]
signing_required=yes
streams=yes
soft=yes
dir_cache_max_cnt=0
protocol_vers_map=6
mc_prefer_wired=yes
    • การตั้งค่านี้ทำให้การสำรองกลับมาทำงานอีกครั้ง แต่ยังมี ความเป็นไปได้ว่าอัปเดต macOS ในอนาคตจะทำให้พังอีก

  • แนะนำให้ ปรับการตั้งค่า Synology DSM ด้วย

    • เวอร์ชันสูงสุดของ SMB protocol: SMB3
    • เปิดใช้งาน Opportunistic Locking, SMB2 Lease, Durable Handles
    • Server signing: “No” หรือ “Auto”
    • Transport encryption: ปิดใช้งาน
    • ชื่อรายการอาจต่างกันไปตามเวอร์ชันของ UI

กลยุทธ์การสำรองข้อมูลทางเลือก

  • ด้วยความเหนื่อยล้ากับการเปลี่ยนแปลงซ้ำ ๆ ของ Apple จึงกำลังมองหาแนวทาง ลดการพึ่งพา Synology SMB

    • มีการรัน คอนเทนเนอร์ Samba LXC บนเซิร์ฟเวอร์ Proxmox (แบ็กเอนด์ ZFS)
    • เพื่อใช้เป็นปลายทางของ Time Machine จึงกำลังทดสอบ อิมเมจ Docker mbentley/timemachine
    • ตัวอย่าง Docker Compose มีการตั้งค่าผู้ใช้ กลุ่ม พาธของโวลุม และสิทธิ์ต่าง ๆ รวมอยู่ด้วย

  • ตอนนี้แนวทางแก้ไขแรกยังใช้งานได้ แต่มีแผนจะ ย้ายไปใช้โซลูชันบน Docker

    • ในสภาพแวดล้อม Docker สามารถควบคุมการทำงานของ SMB ได้โดยตรง จึง ตัดการพึ่งพาซอฟต์แวร์ของ Synology ได้

การพิจารณา Borg Backup

  • กำลังใช้ Borg Backup บน Fedora และพิจารณาจะนำมาใช้บน macOS ด้วย
    • ยังไม่ได้ทดสอบ GUI client อย่าง Vorta แต่ถูกกล่าวถึงว่าเป็นทางเลือกที่น่าสนใจ

ปัญหา iOS เพิ่มเติม

  • ระหว่างตั้งค่าอุปกรณ์ iOS ใหม่ ยังพบบั๊ก “Restore in Progress: An estimated 100 MB will be downloaded…” อยู่เหมือนเดิม
    • เป็นปัญหาที่เกิดซ้ำมาตลอด 6 ปี และครั้งนี้ก็ยังต้อง รีเซ็ตการตั้งค่าเครือข่ายและรีบูต 3 ครั้ง จึงจะแก้ได้
    • เน้นย้ำว่า Apple ควร ให้ความสำคัญกับคุณภาพของระบบปฏิบัติการและประสบการณ์ผู้ใช้มากขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-03
ความคิดเห็นจาก Hacker News
  • หากตั้งค่า Time Machine ให้ใช้ การสำรองข้อมูลแบบเข้ารหัส มันจะสร้างดิสก์ปลอมในรูปแบบโครงสร้างไดเรกทอรี และภายในมีไบนารีชังก์ขนาดหลาย GB อยู่
    วิธีนี้ทำให้ระบบไฟล์ไม่จำเป็นต้องรองรับ symbolic link หรือชื่อไฟล์ Unicode ที่ไม่แยกตัวพิมพ์เล็กใหญ่ จึงปลอดภัยกว่า
    ข้อเสียคือการกู้คืนด้วยระบบอื่นที่ไม่ใช่ Mac ทำได้ค่อนข้างลำบาก
    • เห็นด้วยอย่างยิ่ง จากประสบการณ์ของผม วิธี encrypted sparse bundle เสถียรกว่ามาก
      ย้ายไป NAS ก็ไม่มีปัญหา และกู้คืนได้สมบูรณ์แบบ แน่นอนว่าของแบบนี้อาจต่างกันไปในแต่ละคน
    • ยังสามารถสร้าง unencrypted sparse bundle เพื่อใช้งานกับตำแหน่งเครือข่ายที่ Time Machine ไม่รองรับได้ด้วย
  • คำถามที่ใหญ่กว่าคือทำไม Time Machine ยังใช้ network file system อยู่
    มันไม่เสถียรเกินกว่าจะเชื่อถือได้ ช่วงหลังอาจดีขึ้นหน่อยเพราะ APFS แต่สุดท้ายก็ยังเกิดเหตุการณ์ที่แบ็กอัปหายทั้งชุดซ้ำๆ
    ผมใช้ Arq สำหรับแบ็กอัปรายวัน และใช้ Time Machine แค่สำหรับแบ็กอัปรายชั่วโมง ถ้า Time Machine พังก็ยังมีแบ็กอัปรายวันบนคลาวด์ให้สบายใจได้
    • ปัญหาคือ Apple ไม่ได้ทำ quality control อย่างเหมาะสม โซลูชันแบ็กอัปอื่นๆ ทำงานผ่านเครือข่ายได้ดี และไม่ได้ปกปิดความล้มเหลวด้วย
    • ถ้าจำเป็นต้องแบ็กอัปไปยัง network drive ก็อดคิดไม่ได้ว่ามีทางเลือกอื่นอะไรบ้าง
    • ผมไม่เคยใช้ Time Machine แต่ rsync ทำงานได้ดีมากทั้งแบบโลคัลและผ่านเครือข่าย
      มันรองรับการส่งต่อบางส่วนที่ค้างไว้และการเทียบ checksum ด้วย เลยไม่เข้าใจว่าทำไมการแบ็กอัปผ่านเครือข่ายถึงต้องเป็นปัญหา
  • ผมก็แบ็กอัปไปยัง Synology NAS บนเวอร์ชัน Tahoe เหมือนกัน และสูญเสียแบ็กอัปไปหลายครั้งจากปัญหาที่ไม่รู้สาเหตุ
    ไม่มีไฟล์ /etc/nsmb.conf ด้วย และแม้จะตั้งค่าตามหลายบทความสอนแล้ว สุดท้ายก็ยัง crash แล้วเสียทุกอย่างอีก
  • ผมเป็นแฟนของ SuperDuper ใช้มันทำแบ็กอัปแบบ differential ลง SSD ทุกวัน
    แม้จะไม่ใช่แบ็กอัปรายชั่วโมงแบบ Time Machine แต่เป็นแบ็กอัปที่บูตได้ทันทีหากดิสก์ระบบพัง
    จะทำด้วย cron กับ rsync ก็ได้ แต่ขี้เกียจ
    ลิงก์แนะนำ SuperDuper
    • ถ้า Apple ไม่ทำให้ความสามารถนั้นพังด้วยอัปเดตก็คงโอเค
      บทความที่เกี่ยวข้อง: You’re a mean one, Apple
    • ผมก็เอาแต่คิดว่าควรซื้ออันนี้สักที
      อินเทอร์เฟซกู้คืนที่มีมาให้ในเครื่องก็โอเค แต่ถ้ามี แบ็กอัปที่บูตแบบออฟไลน์ได้ ก็อุ่นใจกว่ามาก
      กำลังคิดว่าจะตั้งเวลาให้ดัมป์อิมเมจบูตลงดิสก์ภายนอกเดือนละครั้ง
  • หลัง อัปเกรด Tahoe ผมกำลังพยายามแก้ปัญหา Time Machine USB backup
    แบ็กอัปแรกเริ่มได้บนดิสก์ที่ฟอร์แมตใหม่ แต่ช้ามาก และถึงแม้จะขึ้น 100% แล้วก็ไม่ยอมจบ
    พอรันอีกครั้งก็ค้างแถว 10% ลองมาหมดแล้วทั้งหลายดิสก์ safe mode ปิดเครือข่าย ก็ยังเหมือนเดิม
    แต่ใช้ tar แบ็กอัปได้ปกติ ดูเหมือนจะไม่มีใครทดสอบ edge case
  • ดูเหมือน Time Machine จะได้รับคำชมเกินจริง
    อาจเป็นเพราะ อินเทอร์เฟซเลื่อนดูที่หวือหวา ก็ได้
    แต่ในความเป็นจริงแบ็กอัปผ่านเครือข่ายไม่เสถียร และพอผ่านไปไม่กี่เดือนก็มักแจ้งว่าแบ็กอัปเสียหายแล้วให้เริ่มใหม่ตั้งแต่ต้น
    • เมื่อก่อน Time Machine มอบ ประสบการณ์แบ็กอัปที่เชื่อถือได้ จริงๆ
      ถ้าเคยใช้แต่เวอร์ชันยุคที่ quality control หายไปแบบตอนนี้ ก็คงยากจะเข้าใจว่าทำไมมันถึงเคยได้รับความนิยม
    • Time Machine แทบจะเป็นโซลูชันเดียวที่ทำให้ผู้ใช้ทั่วไปมี นิสัยการแบ็กอัป
      แค่เสียบ USB แล้วกด “ใช่” ก็จบ ถึงจะไม่สมบูรณ์แบบแต่ก็ดีกว่าไม่มีมาก
    • ผมก็ใช้เพราะชอบ UI แบบไทม์ไลน์ นั่นแหละ
      มันช่วยย้อนกลับไปดูสถานะในอดีตได้ง่ายเหมือน git แต่ใช้ความคิดน้อยกว่า git
    • เวลาแบ็กอัปไปยังระบบโลคัลมันเสถียรมาก และยังเปิดดูผ่าน Finder ได้ด้วย
      ส่วนแบ็กอัปผ่านเครือข่ายก็ทำงานได้ดีมาหลายปีแล้ว
    • สำหรับผมมันทำงานได้ดี ตอนเปลี่ยนไปใช้โน้ตบุ๊กเครื่องใหม่ แค่ระบุ network backup ก็คืนสภาพแวดล้อมเดิมทั้งหมดได้ภายในหนึ่งชั่วโมง
  • แบ็กอัป Time Machine เสียหาย บ่อยเกินไป สุดท้ายผมเลยเขียนสคริปต์ incremental backup ด้วย rsync เอง
    พอใจกว่ามาก ดู สคริปต์นี้ ไว้เป็นตัวอย่าง
    • ผมก็มีประสบการณ์แบบเดียวกัน และเสริมกลยุทธ์แบ็กอัปให้แข็งแรงขึ้นตอนย้ายจาก HFS+ ไป zfs
      ถ้าต้องเริ่มใหม่ตอนนี้ ผมน่าจะใช้ rustic-rs หรือ borg backup
      ถึงอย่างนั้นก็ยังเก็บ local snapshot ไว้ด้วย tmutil localsnapshot
  • คุณภาพของอัปเดตรายปี ของ macOS แย่ลงเรื่อยๆ และ Tahoe ก็แย่ที่สุดในบรรดานั้น
    Apple ต้องเปลี่ยนทิศทางแล้ว
    • ตั้งแต่ High Sierra เป็นต้นมา ผมจะรออย่างน้อย 8 เดือนหลังเมเจอร์เวอร์ชันใหม่ออกค่อยอัปเดต
      ตอนนั้นจะมีแพตช์ออกมาหลายรอบจนเสถียรแล้ว ผมใช้ช้ากว่าอยู่หนึ่งปีเสมอ แต่ก็ไม่ได้ต้องการฟีเจอร์ใหม่ขนาดนั้น
  • เผื่อไว้เป็นข้อมูล ในสเปนมีการบล็อกเว็บไซต์จำนวนมากเพราะปัญหา ลิขสิทธิ์การถ่ายทอดสดฟุตบอล
    เพราะงั้นวันนี้ผมเลยดูเนื้อหาไม่ได้ ตั้งใจว่าจะลองใหม่พรุ่งนี้
    • ผมก็เคยเห็นเรื่องนี้ใน Reddit เหมือนกัน เป็นนโยบายที่แปลกมากจริงๆ
  • ตอนนี้ดูเหมือน Apple จะมองว่าผู้ใช้ที่ยังใช้ Time Machine มีไม่มากพอแล้ว
    เลยคิดว่าบริษัทกำลังค่อยๆ เปลี่ยนไปสู่ การสำรองข้อมูลที่เน้น iCloud
    • แต่นั่นไม่ใช่ แบ็กอัปจริงๆ