บทวิเคราะห์หลังเหตุการณ์บริการ Tarsnap หยุดให้บริการ

 (mail.tarsnap.com)
1 คะแนน โดย GN⁺ 2023-07-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เซิร์ฟเวอร์กลางของ Tarsnap บน Amazon EC2 us-east-1 ล่มด้วยสถานะ failed system status check ทำให้บริการหยุดให้บริการเป็นเวลาประมาณ 26 ชั่วโมง 16 นาที นับตั้งแต่ราว 2023-07-02 13:07:58 UTC
  • ตรวจพบเหตุขัดข้องเมื่อ 13:10 UTC แต่มีการใช้หลักปฏิบัติด้านปฏิบัติการที่ปิดการเริ่มทำงานอัตโนมัติของโค้ดเซิร์ฟเวอร์ไว้ เพื่อให้มนุษย์ตรวจสอบเองหลังการรีบูตที่ไม่คาดคิด
  • การกู้คืนดำเนินการโดยอ่าน เฮดเดอร์เมทาดาทา จากระบบไฟล์แบบ log-structured บน Amazon S3 แล้วนำงานมาเล่นซ้ำตามลำดับในเครื่อง โดยขั้นแรกเสร็จเมื่อ 2023-07-03 01:49:49 UTC
  • ระหว่างกระบวนการสร้างสถานะขึ้นใหม่ พบกรณีที่ไม่ได้ทดสอบของการจัดการ machine re-owned ที่เขียนไว้ในปี 2014 และการลืมตั้งค่าเริ่มต้นของลอจิกการดำเนินการต่อ อีกทั้งขีดจำกัด throughput ของดิสก์ก็ทำให้การกู้คืนช้าลง
  • แม้ Tarsnap ไม่มี SLA ที่ชัดเจน แต่ตามนโยบายที่ให้เครดิตสำหรับเหตุขัดข้องที่เห็นว่ายุติธรรม จึงมอบ เครดิต 50% ของค่าพื้นที่จัดเก็บหนึ่งเดือนให้ทุกบัญชีเมื่อ 2023-07-13

การเกิดเหตุขัดข้องและการตอบสนองเบื้องต้น

  • ราว 2023-07-02 13:07:58 UTC เซิร์ฟเวอร์กลางของ Tarsnap ออฟไลน์ในรีเจียน Amazon EC2 us-east-1
    • สถานะ EC2 คือ failed system status check
    • สำหรับเครื่องเสมือน สถานะนี้อาจบ่งชี้ได้หลายสาเหตุ เช่น ไฟดับ ฮาร์ดแวร์ของเซิร์ฟเวอร์จริงล้มเหลว หรือเครือข่าย EC2 ขัดข้อง
    • ในช่วงเวลาเดียวกันไม่พบรายงานเหตุขัดข้องของ EC2 เป็นวงกว้าง จึงมองว่าน่าจะเป็นความล้มเหลวของฮาร์ดแวร์แบบแยกส่วนมากที่สุด
  • ระบบมอนิเตอร์ตรวจพบเหตุขัดข้องเมื่อ 2023-07-02 13:10 UTC
    • เฝ้าระวังโดยทำการเขียน อ่าน และลบ archive ทุก 5 นาทีจากรีเจียน EC2 อื่น
    • การแจ้งเตือนทางข้อความเมื่อ 13:10 UTC ไม่สามารถปลุกได้ แต่การแจ้งเตือนทางโทรศัพท์เมื่อ 13:15 UTC ทำให้เริ่มตอบสนอง
    • จากการตรวจสอบเบื้องต้นไม่พบข้อผิดพลาดชั่วคราวที่ชัดเจน จึงสรุปว่าระบบตายแล้วและเริ่มเตรียมอินสแตนซ์ EC2 ทดแทน

หลักปฏิบัติด้านปฏิบัติการที่หลีกเลี่ยงการรีสตาร์ตอัตโนมัติ

  • ราว 2023-07-02 13:52 UTC Amazon รีสตาร์ตเซิร์ฟเวอร์ที่มีปัญหาบนอินสแตนซ์ EC2 ใหม่
    • เป็นเวลาประมาณ 45 นาทีหลังเริ่มเกิดเหตุขัดข้อง
    • ระบบปฏิบัติการ FreeBSD บูตขึ้นมา แต่โค้ดเซิร์ฟเวอร์ของ Tarsnap ไม่ได้เริ่มทำงานโดยอัตโนมัติ
  • เหตุผลที่ปิดการเริ่มทำงานอัตโนมัติไว้ คือเพื่อให้ตรวจสอบสถานะด้วยตนเองก่อนรับทราฟฟิกหลังการรีบูตที่ไม่คาดคิด
    • ตามหลักปฏิบัติด้านปฏิบัติการ “การป้องกันข้อมูลสูญหายเมื่อมีบางอย่างพัง” สำคัญกว่า “การเพิ่มความพร้อมใช้งานของบริการให้สูงสุด”
  • หลังรีบูต ล็อกของเซิร์ฟเวอร์แสดง ความเสียหายของระบบไฟล์
    • มองว่าสาเหตุของเหตุขัดข้องอาจทำให้ฮาร์ดแวร์ตาย หรือทำให้การเชื่อมต่อระหว่างเซิร์ฟเวอร์กับ Elastic Block Store ที่เก็บระบบไฟล์ถูกตัด
    • จึงตัดสินใจตั้งค่าเซิร์ฟเวอร์ใหม่ต่อไป แทนการกู้คืนเซิร์ฟเวอร์เดิม

โครงสร้างล็อกบน S3 และขั้นตอนการกู้คืน

  • บริการ Tarsnap จัดเก็บข้อมูลใน Amazon S3 เป็น ระบบไฟล์แบบ log-structured
    • แต่ละ S3 object มีเฮดเดอร์ที่บรรจุเมทาดาทาของรายการล็อกทั้งหมด และอาจมีข้อมูลของรายการล็อกด้วย
    • รายการล็อก start write transaction มีเฉพาะเฮดเดอร์ที่ระบุเครื่องและ transaction nonce โดยไม่มีข้อมูลล็อก
    • รายการล็อก store data block มีทั้งเฮดเดอร์ที่ระบุเครื่องและชื่อบล็อก รวมถึงข้อมูลบล็อก
  • ในสถานะปกติ เมทาดาทาของรายการล็อกจะถูกแคชไว้บน EC2 และจะไม่อ่านซ้ำจาก Amazon S3
    • การอ่านจาก Amazon S3 จะเกิดขึ้นเฉพาะเมื่ออ่านข้อมูลบล็อกเพื่อตอบสนองคำขอจากไคลเอนต์ tarsnap
  • การกู้คืนสถานะของอินสแตนซ์ EC2 แบ่งเป็นสองขั้น
    • ขั้นแรก อ่าน เฮดเดอร์เมทาดาทา ทั้งหมดจาก S3
    • จากนั้น เล่นซ้ำ (replay) งานทั้งหมดในเครื่อง
    • ในระบบจัดเก็บแบบ log-structured เมื่อมีการลบข้อมูล รายการล็อกจะถูกเขียนใหม่เพื่อคืนพื้นที่จัดเก็บ ดังนั้นจึงไม่สามารถทำสองขั้นนี้พร้อมกันได้
    • รายการล็อกมีหมายเลขลำดับ จึงสามารถเล่นซ้ำตามลำดับที่ถูกต้องได้ แต่ต้องจัดเรียงหลังจากค้นหาก่อน

ข้อบกพร่องและคอขวดที่พบระหว่างการกู้คืน

  • ขั้นแรกดำเนินไปโดยไม่มีปัญหาและเสร็จเมื่อ 2023-07-03 01:49:49 UTC
    • โปรเซสกู้คืนถูกตั้งค่าให้ส่งคำขอพร้อมกันไปยัง Amazon S3 จำนวน 250 รายการ
    • ค่านี้เป็นการตั้งค่าตามระดับที่ Amazon S3 รองรับได้เมื่อ 10 ปีก่อน และปัจจุบันน่าจะสามารถเพิ่มได้มาก
  • ขั้นที่สองล้มเหลวแทบจะทันที
    • เกิดข้อผิดพลาดว่ารายการล็อกที่ถูกเล่นซ้ำกำลังบันทึกข้อมูลที่เป็นของเครื่องซึ่งไม่มีอยู่
    • สาเหตุคือโค้ดจัดการการย้ายบัญชีของเครื่องที่เขียนไว้ในปี 2014
    • เมื่อผู้ใช้ Tarsnap ต้องย้ายเครื่องข้ามบัญชี จะใช้วิธีบันทึกรายการล็อก machine registration ใหม่แล้วลบรายการเดิม
    • แม้มีการทดสอบอยู่ แต่ขาดกรณีที่สร้างสถานะเซิร์ฟเวอร์ขึ้นใหม่หลังจากเครื่องถูก re-owned ในขณะที่มีข้อมูลถูกจัดเก็บแล้ว
    • เนื่องจากรายการล็อกการลงทะเบียนเครื่องใหม่มีหมายเลขลำดับสูงกว่า ระหว่างการเล่นซ้ำจึงดูเหมือนว่าข้อมูลถูกจัดเก็บลงในเครื่องที่ยังไม่มีอยู่
  • หลังระบุสาเหตุได้แล้ว ได้ปิดการทำงานของ “seatbelt” นั้นและดำเนินการสร้างสถานะขึ้นใหม่ต่อ
    • หลังจากนั้นไม่นานก็เกิดข้อผิดพลาดว่าไม่พบข้อมูลใน Amazon S3
    • เพราะในการพยายามดำเนินการต่อ มีการข้ามขั้นตอนดาวน์โหลดข้อมูลจาก S3 ทำให้ค่า maximum log entry sequence number ไม่ถูกตั้งค่าเริ่มต้นและยังคงเป็น 0
    • หลังแก้ปัญหานี้แล้ว การสร้างสถานะขึ้นใหม่ก็ดำเนินต่อได้ตามปกติ
  • การสร้างสถานะขึ้นใหม่ดำเนินไปช้ากว่าที่จำเป็น
    • หากรู้ว่าคอขวดคือ throughput ของดิสก์ ก็สามารถตั้งค่า throughput ของ EBS volume ที่เกี่ยวข้องให้สูงขึ้นได้
    • เนื่องจากอดนอนจึงไม่สามารถเฝ้าดูโปรเซสได้อย่างใกล้ชิด ไม่เช่นนั้นอาจตรวจพบคอขวดจาก gstat(8) และ Amazon CloudWatch แล้วตั้งค่า EBS volume ใหม่ได้

การกลับมาให้บริการและการให้เครดิต

  • ราว 2023-07-03 15:10 UTC โปรเซสสร้างสถานะขึ้นใหม่เสร็จสิ้น
    • ไม่ได้บันทึกเวลาที่เสร็จสิ้นอย่างแน่นอนไว้
    • วางเซิร์ฟเวอร์ไว้ในโหมดอ่านอย่างเดียวและทำการทดสอบอย่างรวดเร็ว
    • ตรวจสอบว่าเมื่อเทียบกับสถานะของเซิร์ฟเวอร์เดิมแล้ว ตรงกันยกเว้นข้อมูลไม่กี่วินาทีสุดท้ายที่ระบบไฟล์ของเซิร์ฟเวอร์เดิมสูญเสียไป ณ เวลาที่เกิดเหตุขัดข้อง
  • ทราฟฟิกจริงครั้งแรกหลังเหตุขัดข้องเกิดขึ้นเมื่อ 2023-07-03 15:25:58 UTC
    • เป็นเวลาประมาณ 26 ชั่วโมง 16 นาที หลังเริ่มเกิดเหตุขัดข้อง
  • Tarsnap ไม่มี SLA ที่ชัดเจน แต่ใช้นโยบายให้เครดิตสำหรับเหตุขัดข้องที่ดูยุติธรรม
    • เมื่อ 2023-07-13 ได้มอบเครดิต 50% ของค่าพื้นที่จัดเก็บหนึ่งเดือนให้กับทุกบัญชี Tarsnap
    • การดำเนินการเครดิตเกิดขึ้นหลังจากจัดการเหตุขัดข้องและได้พักผ่อนแล้ว

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

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

 
GN⁺ 2023-07-28
ความคิดเห็นบน Hacker News

  • นึกไม่ถึงจริง ๆ ว่าบทความนี้จะขึ้นไปอยู่บนสุดของ HN อยากตอบคำถามนะ แต่ตอนนี้สี่ทุ่มแล้ว และลูกหลับไปตั้งแต่ห้าโมงเย็น ถ้าโชคดีน่าจะได้นอนสัก ประมาณ 4 ชั่วโมง ก่อนที่ลูกจะตื่น
    ตอนเช้าจะกลับมาตรวจดูและตอบคำถาม

    • อยากรู้ว่ามีเหตุผลอะไรที่ควรใช้บริการนี้แทน restic ขอบคุณ Colin นะ แต่จากบทความนี้ดูเหมือนว่า ผู้รับผิดชอบโครงสร้างพื้นฐาน ของบริการนี้มีอยู่จริง ๆ แค่คนเดียว
      การระบุชัดเจนว่าไม่มี SLA นั้นดี แต่รู้สึกเหมือนมีความเสี่ยงใหญ่ ๆ คั่นอยู่ระหว่างตัวผมกับแบ็กอัพของผม
    • ถ้าต่อไปต้องเขียน postmortem อีก ซึ่งแน่นอนว่าหวังว่าจะมีน้อยมากหรือไม่มีเลย อยากให้เขียน บทเรียนที่ได้ ให้ชัดเจน เพื่อให้เห็นว่าประเด็นไหนจะไม่เกิดซ้ำอีก และเพราะอะไร
    • เป็น postmortem ที่เขียนดีและรอบคอบมากจริง ๆ แต่หวังว่าจะไม่ต้องได้เห็นบทความแบบนี้อีก :)
    • ถึงเวลามอบหมาย ซัพพอร์ต 24 ชั่วโมง ให้ลูกแล้ว ;)
      อ่าน https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... แล้วก็เห็นผลอยู่บ้าง หาได้ตามห้องสมุดทุกแห่ง หรือก็คือ Blockbuster สำหรับหนังสือนั่นแหละ
    • อยากรู้ว่า ทรานแซกชันล็อก ถูกเก็บไว้นานแค่ไหนก่อนจะถูกเขียนทับ
      ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมเองก็มีอินสแตนซ์ EC2 บางตัวล่มลงโดยมีอาการเหมือนถูกตัดจาก EBS และกรณีของผมอยู่ใน eu-west

  • ส่วนที่บอกว่า “Tarsnap ไม่มี SLA แต่ถ้าดูยุติธรรมก็จะให้เครดิตสำหรับเหตุขัดข้อง” ตามนโยบายที่ค่อนข้างคลุมเครือนี้ แล้วในวันที่ 2023-07-13 ก็เติมเครดิต 50% ของค่าจัดเก็บหนึ่งเดือนให้บัญชี Tarsnap ของทุกคน แสดงให้เห็นดีว่า Percival เป็นคนแบบไหน
    เครดิตนี้ดูค่อนข้างใจกว้างในแง่ของการ ชดเชยให้ลูกค้าอย่างเพียงพอ และต่างจากผู้ให้บริการคลาวด์รายใหญ่ ๆ ตรงที่ไม่ได้ทำให้ลูกค้าแต่ละรายต้องมาร้องขอเอง แถมยังมี postmortem ที่ชัดเจน เป็นเทคนิค และละเอียดอีกด้วย ผมคิดว่าทุกที่ควรทำแบบนี้

    • สำนวนว่า “ขอบคุณที่เป็นประภาคารในความมืด” นั้นตรงมาก
      ค่อนข้างดีใจที่ได้อยู่ในโลกที่มี Tarsnap อยู่ และคิดราคาเป็นหน่วย picodollars

  • ถ้าตั้งค่าและทดสอบ ขั้นตอนกู้คืนจากภัยพิบัติ ไว้อย่างเหมาะสม ก็น่าจะลด downtime ได้มากกว่านี้มาก
    จำเป็นต้องสร้างระบบ staging แยกต่างหากเต็มรูปแบบ ทำให้สามารถปิดแล้วสร้างใหม่ได้ ทดสอบโหมดความล้มเหลวต่าง ๆ เป็นระยะ และจัดทำเอกสารรายละเอียดขั้นตอนทั้งหมดของการกู้คืนระบบ
    ในระยะยาวก็น่าลองคิดดูว่าจะเพิ่มรายได้จนสามารถจ้าง พนักงานพาร์ตไทม์ ซึ่งจะช่วยได้มากเมื่อเกิดเรื่องคล้าย ๆ กันได้หรือไม่
    เราก็เป็นผู้ให้บริการโซลูชันคลาวด์รายเล็ก และโฟกัสที่ ML API เช่นกัน แต่ยิ่งเวลาผ่านไปก็ยิ่งชัดเจนว่าเมื่อใช้ฮาร์ดแวร์คลาวด์ ไม่ว่าจะเป็นแบบ dedicated หรือ virtual ความขัดข้องจะเกิดขึ้นเป็นระยะ ๆ RAM, HDD หรือชิ้นส่วนฮาร์ดแวร์อื่น ๆ อาจเสียได้ทุกเมื่อ ดังนั้นหากจะให้บริการออนไลน์แบบ high availability ในระยะยาว ต้องคำนึงถึงเรื่องนี้ 100%

  • ขอชื่นชม postmortem ที่ซื่อสัตย์และการรับมือกับสถานการณ์ยาก ๆ ได้ดี อย่างไรก็ตาม ในเรื่อง การอดนอน ถ้ามีคนที่แก้ปัญหาได้อยู่แค่คนเดียว ก็ไม่จำเป็นต้องอายที่จะยอมรับเวลา outage เพิ่มขึ้นอีกเล็กน้อยเพื่อให้มีสติปลอดโปร่ง
    การไปนอนสักพักในขณะที่สัญญาณเตือนกำลังดังอาจรู้สึกแปลก ๆ แต่เมื่ออะดรีนาลีนผสมกับการนอนไม่พอ มันง่ายมากที่จะทำให้ปัญหาแย่ลง

    • ไม่ต้องห่วง ระหว่างนั้นได้นอนงีบไปหลายครั้งอยู่ “อันนี้ดูเหมือนจะทำงานได้ดี แต่ยังต้องใช้เวลาอีกหลายชั่วโมง งั้นตั้งปลุกอีก 2 ชั่วโมงแล้วนอนหน่อยดีกว่า” เป็นหนึ่งในเหตุผลที่ผมไม่ทันสังเกตว่าขั้นตอนที่สองติด คอขวด I/O โดยไม่จำเป็น

  • จากคำอธิบาย ดูเหมือนว่า กระบวนการกู้คืน นี้น่าจะทดสอบเป็นประจำได้ค่อนข้างง่าย และน่าจะช่วยจับบั๊กที่ยังเหลืออยู่หรือประเมินเวลาการกู้คืนได้
    อย่างที่มักพูดกันว่า แบ็กอัพที่ได้ทดสอบแล้วเท่านั้นถึงจะเป็นแบ็กอัพจริง

    • เห็นด้วย 100% ในฐานะคนที่เพิ่งรู้หลังจากทดสอบว่า กระบวนการกู้คืนจากภัยพิบัติ ของตัวเองใช้ไม่ได้ แผนที่มีโอกาสใช้งานได้จริงคือแผนที่ทำซ้ำได้และผ่านการทดสอบแล้วเท่านั้น
    • ใช่เลย ตั้งใจจะทำมาสักพักแล้ว แต่ก็มักมีงานที่มีลำดับความสำคัญสูงกว่าเสมอ จนก่อนเกิดเหตุขัดข้องครั้งนี้ ผมไม่รู้ตัวเลยว่าแทบจะ ไม่ได้ทดสอบมา 10 ปี แล้ว
      จากนี้ไปจะจัดให้การซ้อมประจำปีมีลำดับความสำคัญสูงอย่างแน่นอน

  • การได้เห็น postmortem ที่เป็นมืออาชีพ สุภาพ และซื่อสัตย์แบบนี้เป็นเรื่องดีเสมอ

  • อาจจะพูดโดยอิงจากข้อมูลบริษัท Tarsnap ที่เก่าแล้วก็ได้ แต่ปัจจัยเดียวที่ทำให้ผมลังเลที่จะใช้ Tarsnap อย่างจริงจังคือ เหตุขัดข้อง Colin Percival แบบไม่คาดคิด หรือก็คือความเสี่ยงจากบุคคลสำคัญ
    ผมคิดว่าคงไม่ใช่แค่ผมคนเดียว

    • คล้ายกับการคำนวณค่าเฉลี่ยระยะเวลาระหว่างความขัดข้อง คือเป็นคำถามว่าจะเชื่อโซลูชันที่ออกแบบมาดีของบริษัทคนเดียวซึ่งมีชิ้นส่วนเคลื่อนไหวน้อยและออกแบบมาดี หรือจะเชื่อโซลูชันของบริษัทที่ใหญ่กว่ามาก แต่มีชิ้นส่วนเคลื่อนไหวมากกว่ามาก และอาจออกแบบมาแย่กว่าด้วย
      ส่วนตัวผมจะเลือกวิธีที่เรียบง่ายกว่า จากประสบการณ์ของผม การจะไปให้ถึงระดับความน่าเชื่อถือของระบบที่เรียบง่าย ต้องเพิ่มความซับซ้อนเข้าไปมหาศาล และความซับซ้อนส่วนใหญ่ทำให้สถานการณ์แย่ลง
      เรื่องนี้เห็นได้ชัดในการทำเซิร์ฟเวอร์คลัสเตอร์ เซิร์ฟเวอร์เดี่ยวที่มีไฟฟ้าและเครือข่ายเสถียร จะน่าเชื่อถือกว่าความพยายามใด ๆ ที่จะทำบริการนั้นให้ซ้ำซ้อน จนกว่าจะไปถึงระดับที่ต้นทุนและความซับซ้อนเพิ่มขึ้นราว 5 เท่า ถึงตอนนั้นจึงจะได้ค่าเฉลี่ยระยะเวลาระหว่างความขัดข้องใกล้เคียงกับเซิร์ฟเวอร์เดี่ยว และหลังจากนั้นจึงค่อยปรับปรุงได้จริง
      ผมเชื่ออย่างแรงกล้าว่าเส้นทางที่ดีที่สุดสู่ความน่าเชื่อถือจริง ๆ คือ ความเรียบง่ายเท่าที่เป็นไปได้ และการมีแบ็กอัปที่ดี หากต้องการความพร้อมใช้งาน 24 ชั่วโมง 7 วันต่อสัปดาห์ ตัวเลือกทางเทคโนโลยีที่ใช้ได้ก็จะถูกจำกัดลงค่อนข้างมาก
    • ผมเข้าใจว่านี่เป็นความเสี่ยง แต่ก็ไม่มั่นใจว่ามันต้องเสี่ยงกว่าบริษัทใหญ่เสมอไป
      นี่คืองานของ Colin มีชื่อของ Colin ติดอยู่ และมันสำคัญกับ Colin มาก
      ที่ BigBackupCorp คงยากจะได้บริการแบบเดียวกัน พนักงานก็เปลี่ยนแทนกันได้ ผู้บริหารก็เปลี่ยนแทนกันได้ และพูดตรง ๆ ผมในฐานะลูกค้าก็เป็นสิ่งที่เปลี่ยนแทนได้เช่นกัน ถ้าบริษัทเปลี่ยนทิศทางและตัดสินใจจะกลายเป็น BigFlowerArrangementShippingCorp
      ข้อดีของธุรกิจขนาดเล็กคือมันขับเคลื่อนด้วยผลประโยชน์ของตัวเองล้วน ๆ ไม่มีการเล่นราคาหุ้นหรือกลเม็ดแบบ VC ถ้าเป็นธุรกิจที่ทำกำไรได้ ก็จะมีใครสักคนเข้ามาซื้อกิจการ แล้วเอาชื่อตัวเองแขวนไว้และทำให้เป็นงานของตัวเอง ผมคิดว่าอินเทอร์เน็ตแบบเปิดได้ประโยชน์มากจากสิ่งแบบนี้
    • ถ้าลองทำรายชื่อคู่แข่งที่หายไปก่อน Tarsnap การคำนวณอาจเปลี่ยนไปเล็กน้อย ความเสี่ยงที่ควรประเมินไม่ใช่ “ถ้ามีอะไรเกิดขึ้นกับผู้ให้บริการจะเป็นอย่างไร?” แต่ควรเป็น “ถ้ามีอะไรเกิดขึ้นกับเขา บริการก็ล่ม และผมไม่ได้ทำ แบ็กอัปของแบ็กอัป ไว้ด้วย จะเป็นอย่างไร?”
      ความเสี่ยงนี้สามารถทำให้เล็กลงได้เท่าที่ต้องการด้วยการวางแผนอย่างรอบคอบ
    • ถ้าคุณดู HN อยู่ ก็น่าจะรู้ภายใน 24 ชั่วโมงหากมีปัญหาเกิดขึ้นกับ Colin ในทางปฏิบัติ ปัญหาจริง ๆ จะเกิดขึ้นก็ต่อเมื่อที่เก็บข้อมูลหลัก, Tarsnap และ Colin ล้มเหลวพร้อมกันทั้งหมดใน กรอบเวลาประมาณ 24 ชั่วโมง ก่อนที่คุณจะย้ายไปยังผู้ให้บริการแบ็กอัปรายใหม่
    • ผมไม่ได้คิดจะเชื่อใจผู้ให้บริการแบ็กอัปมากไปกว่านั้น เพราะทันทีที่พึ่งพามัน มันจะล้มเหลวในเวลาที่ลำบากที่สุด
      บริการอย่าง Tarsnap ควรเป็นเพียงหนึ่งในหลายชั้น และควรสร้าง แบ็กอัปหลายชั้น พร้อมตรวจสอบเป็นประจำ

  • ข้อผิดพลาดอย่างรายการ log ที่ถูก replay บันทึกข้อมูลของเครื่องที่ไม่มีอยู่จริง น่าจะจับได้ด้วยการเขียน โมเดล TLA+

  • ถ้าใช้ชุดอย่าง restic+backblaze ค่าใช้จ่ายจะต่ำลงหลายหลัก เลยสงสัยว่าข้อดีของการใช้ Tarsnap คืออะไร ไม่รู้ว่าต้องมีความต้องการเฉพาะแบบไหนถึงจะมีแรงจูงใจจ่าย 3000 ดอลลาร์ต่อ TB-ปี

    • พวกเราบางคนมีเงินเหลืออยู่พอสมควร และชอบมีข้ออ้างที่จะจ่ายเงินให้ cperciva เพื่อให้เขาไม่ต้องไปทำงานแย่ ๆ และได้ใช้ทักษะกับพรสวรรค์ของเขากับงานที่ใหญ่และดีกว่า
      สำหรับคนที่ถามเรื่อง bus factor ต่ำ คุณคงไม่ได้เก็บแบ็กอัปไว้กับบริการเดียวหรือที่เดียวใช่ไหม? คุณคงใช้ Tarsnap ร่วมกับ Restic+Backblaze, Rsync.net, S3 ฯลฯ ใช่ไหม? “แบ็กอัปคือภาษีที่จ่ายเพื่อให้ได้ความหรูหราในการกู้คืน”
    • การลบข้อมูลซ้ำซ้อน ทำได้ดีมาก จนค่าใช้จ่ายของชุดข้อมูลสำคัญมาก ๆ ที่ผมแบ็กอัปไว้กับ Tarsnap แทบไม่ต้องสนใจ หากข้อมูลเปลี่ยนบ่อยกว่านี้ การคำนวณคงต่างออกไป
      ตัวอย่างเช่น ผมใช้บริการอื่นสำหรับไลบรารีวิดีโอและภาพถ่าย แต่แบ็กอัปฐานข้อมูลบัญชีและเอกสารสำคัญไว้กับ Tarsnap
      ผมใช้ Tarsnap มา 10 ปีแล้ว แทบไม่เคยมีปัญหาด้านความพร้อมใช้งาน และเท่าที่จำได้ก็แทบไม่เคยมีปัญหาใด ๆ เลย

  • ฟังดูเหมือนว่า downtime 26 ชั่วโมงส่วนใหญ่ถูกใช้ไปกับการกู้คืนแบ็กอัป บังเอิญว่านี่เป็นเหตุผลตรง ๆ ที่ผมใช้ Tarsnap ใน สภาพแวดล้อม production ไม่ได้
    ในมุมผู้ใช้ การกู้คืนแบ็กอัปช้าจนน่าทรมาน ผมไม่มีความอดทนจะรอหลายชั่วโมงเพราะบริการแบ็กอัปตอนที่ระบบของผมออฟไลน์อยู่ ตอนนี้อาจดีขึ้นแล้วก็ได้ แต่ครั้งสุดท้ายที่ผมลองใช้เมื่อหลายปีก่อน การกู้คืนแบ็กอัปไม่กี่ GB ใช้เวลาประมาณระดับเป็นชั่วโมง