pgbackrest/pgbackrest
(github.com/pgbackrest)- เป็นเครื่องมือสำรองและกู้คืนข้อมูลสำหรับ PostgreSQL ที่ออกแบบมาให้ขยายสเกลได้ถึงสภาพแวดล้อมขนาดใหญ่ แต่ปัจจุบันอยู่ในสถานะยุติการบำรุงรักษาแล้ว
- ได้หยุดทั้งการแก้ bug, การ review PR, การตอบสนองต่อ issue และการพัฒนาฟีเจอร์ใหม่ทั้งหมด โดยเลือกที่จะหยุดอย่างชัดเจนแทนการประคองต่อแบบไม่สม่ำเสมอ
- รองรับการสำรองข้อมูลแบบ full, differential, incremental และblock-level backup ทำให้บันทึกและกู้คืนเฉพาะส่วนที่เปลี่ยนแปลงได้ด้วยการรองรับการกลับมาทำงานต่อของงานที่ถูกขัดจังหวะและdelta restore
- มีprotocol layerที่ครอบคลุมทั้งสภาพแวดล้อมแบบ local และ remote รวมถึง multiple repositories และขยายขอบเขตการใช้งานผ่านการเชื่อมต่อ TLS·SSH และ object store ที่เข้ากันได้กับ S3·Azure·GCS
- เป็นเครื่องมือที่มีกลไกประกันความถูกต้องสมบูรณ์อย่างกว้างขวาง เช่น checksum, การรอ WAL segment, fsync และการตรวจสอบ page checksum แต่จากนี้ไปแม้จะมี fork เกิดขึ้น ก็ต้องสร้างความน่าเชื่อถือขึ้นมาใหม่แยกต่างหาก
การยุติการบำรุงรักษาและสถานะของโปรเจกต์
- pgBackRest เป็นเครื่องมือสำรองและกู้คืนข้อมูลสำหรับ PostgreSQL แต่ปัจจุบันไม่ได้รับการบำรุงรักษาอีกต่อไป
- โปรเจกต์ได้หยุดการทำงานแล้ว และประกาศว่าจะไม่ใช้เวลากับการแก้ bug, การ review PR, การตอบสนองต่อ issue หรือการพัฒนาฟีเจอร์ใหม่อีก
- แม้จะพยายามดูแลต่อหลังจากรูปแบบการสนับสนุนและการจ้างงานเดิมสิ้นสุดลง แต่ก็ไม่สามารถจัดหา โอกาสทางอาชีพและสปอนเซอร์ชิปได้เพียงพอสำหรับการดูแลโปรเจกต์ต่อไป
- มองว่าการยุติอย่างชัดเจนดีกว่าการดูแลต่อแบบไม่สม่ำเสมอหรือไม่สมบูรณ์
- ในอนาคตอาจมีใคร fork ไปได้ แต่ในกรณีนั้นจะถือเป็นโปรเจกต์ใหม่ และผู้ดูแลใหม่จะต้องสร้างความน่าเชื่อถือขึ้นมาเอง
ฟีเจอร์หลักของโปรเจกต์
- มุ่งเป้าไปที่การสำรองและกู้คืนข้อมูลที่ขยายสเกลได้ถึงสภาพแวดล้อม PostgreSQL ขนาดใหญ่ โดยเวอร์ชันเสถียรปัจจุบันคือ v2.58.0
- ออกแบบมาเพื่อลดต้นทุนการบีบอัดซึ่งมักเป็นคอขวดระหว่างการสำรองข้อมูล โดยใช้การประมวลผลแบบขนานและวิธีบีบอัดอย่าง lz4 และ zstd
- รองรับการสำรองข้อมูลแบบ full, differential, incremental และไม่ใช่แค่ระดับไฟล์ แต่ยังรองรับblock-level backupเพื่อคัดลอกเฉพาะส่วนที่เปลี่ยนแปลงและประหยัดพื้นที่จัดเก็บ
- สามารถกลับมาทำงานสำรองข้อมูลที่หยุดค้างได้ต่อ และตรวจสอบความถูกต้องสมบูรณ์ของไฟล์ที่คัดลอกไปแล้วอีกครั้งโดยเทียบกับ checksum ใน manifest
- ใน delta restore จะลบไฟล์ที่ไม่มีอยู่ในแบ็กอัปออกก่อน จากนั้นเปรียบเทียบ checksum ของไฟล์ที่เหลือ โดยไฟล์ที่ตรงกันจะคงไว้และกู้คืนเฉพาะไฟล์ที่จำเป็น
การทำงานระยะไกลและการออกแบบที่เก็บข้อมูล
- ผ่านprotocol layerของตัวเอง สามารถทำงานสำรองข้อมูล กู้คืน และ archive ได้ทั้งในสภาพแวดล้อม local และ remote โดยการเชื่อมต่อระยะไกลใช้ TLS/SSH
- protocol layer เดียวกันนี้ยังมีอินเทอร์เฟซสำหรับ query PostgreSQL ทำให้ทำงานได้โดยไม่ต้องเชื่อมต่อระยะไกลเข้า PostgreSQL โดยตรง จึงช่วยเพิ่มความปลอดภัย
- รองรับmultiple repositories ทำให้มีทั้งที่เก็บข้อมูลแบบ local สำหรับการกู้คืนที่รวดเร็ว และที่เก็บข้อมูลแบบ remote สำหรับการเก็บระยะยาวและเพิ่มความซ้ำซ้อนร่วมกันได้
- ที่เก็บข้อมูลยังสามารถอยู่บน S3, Azure, GCS compatible object store ได้ด้วย จึงขยายทั้งความจุและระยะเวลาการเก็บรักษาได้มาก
- สามารถเข้ารหัสที่เก็บข้อมูลเองได้ ทำให้ปกป้องข้อมูลสำรองได้ไม่ว่าจะเก็บไว้ที่ใด
วิธีรับประกันความถูกต้องสมบูรณ์และความสอดคล้อง
- คำนวณchecksumให้กับทุกไฟล์ในแบ็กอัป และตรวจสอบซ้ำตอน restore หรือ verify
- หลังจากคัดลอกไฟล์เสร็จ จะรอจนกว่า WAL segment ทั้งหมดที่จำเป็นต่อการทำให้แบ็กอัปอยู่ในสถานะที่สอดคล้องกันจะมาถึงที่เก็บข้อมูล
- ใช้ fsync ทั้งในระดับไฟล์และไดเรกทอรีในทุกงานเพื่อให้มั่นใจด้านความทนทาน
- หากเปิดใช้ page checksum ใน PostgreSQL จะตรวจสอบ page checksum ของทุกไฟล์ใน full backup และตรวจสอบเฉพาะไฟล์ที่เปลี่ยนแปลงใน differential·incremental backup
- แม้การตรวจสอบ page checksum จะล้มเหลว แบ็กอัปก็จะไม่หยุด แต่จะทิ้งคำเตือนว่าเพจใดล้มเหลว เพื่อให้ตรวจพบ page-level corruption ได้ตั้งแต่เนิ่น ๆ ก่อนที่แบ็กอัปที่ยังใช้งานได้จะหมดอายุ
การจัดการ WAL และการเพิ่มประสิทธิภาพการกู้คืน
- มีคำสั่งเฉพาะสำหรับ WAL push/get และทั้งสองแบบรองรับการประมวลผลขนานและการทำงานแบบ asynchronous โดยออกแบบมาให้ตอบสนองต่อ PostgreSQL ได้เร็วที่สุด
- WAL push จะกำจัดข้อมูลซ้ำโดยอัตโนมัติเมื่อมี WAL segment เดียวกันเข้ามาหลายครั้ง และจะเกิดข้อผิดพลาดหากเนื้อหาแตกต่างกัน
- asynchronous WAL push ให้โปรเซสอื่นรับหน้าที่ส่งและบีบอัด WAL segment แบบขนาน จึงสำคัญอย่างยิ่งกับฐานข้อมูลที่มีปริมาณการเขียนสูงมาก
- asynchronous WAL get จะเก็บ คิว WAL ที่ถูกแตกไฟล์บีบอัดแล้ว ไว้ในเครื่องเพื่อให้พร้อมส่งต่อก่อน replay ได้ทันที ซึ่งมีข้อดีมากเป็นพิเศษบนการเชื่อมต่อที่มี latency สูงหรือที่เก็บข้อมูลอย่าง S3
- ทั้ง WAL push และ get จะเปรียบเทียบเวอร์ชัน PostgreSQL และ system identifier เพื่อตรวจสอบว่าฐานข้อมูลกับที่เก็บข้อมูลตรงกัน จึงลดโอกาสการตั้งค่าตำแหน่ง WAL archive ผิดพลาดได้มาก
ความยืดหยุ่นในการปฏิบัติการและความเข้ากันได้
- สามารถตั้งค่านโยบาย backup retention และarchive expiration แยกตาม full, differential และ WAL เพื่อครอบคลุมช่วงเวลาที่ต้องการได้
- สามารถเก็บแบ็กอัปในรูปแบบ PostgreSQL cluster ได้ตรง ๆ และหากปิดการบีบอัดพร้อมเปิด hard link ก็สามารถบูต PostgreSQL cluster ได้โดยตรงบน snapshot ของที่เก็บข้อมูล
- วิธีนี้มีข้อได้เปรียบสำหรับฐานข้อมูลระดับเทราไบต์ที่ใช้เวลานานในการ restore แบบดั้งเดิม
- รองรับ tablespace อย่างสมบูรณ์ และระหว่าง restore สามารถย้ายแต่ละ tablespace ไปตำแหน่งอื่นหรือ remap รวมไปยังตำแหน่งเดียวได้
- รองรับลิงก์ของไฟล์และไดเรกทอรีด้วย ทำให้ตอน restore สามารถคงตำแหน่งเดิม remap บางส่วนหรือทั้งหมด หรือกู้คืนโดยแปลงเป็นไฟล์·ไดเรกทอรีปกติได้
- รองรับ PostgreSQL 10 เวอร์ชัน ครอบคลุมทั้ง 5 เวอร์ชันที่ยังซัพพอร์ตอยู่และ 5 เวอร์ชันล่าสุดที่ EOL แล้ว เพื่อให้มีเวลาเพียงพอสำหรับการอัปเกรด
แหล่งข้อมูลอ้างอิงและสถานะผู้สนับสนุน
- User guides
- Command reference
- Configuration reference
- ผู้สนับสนุนปัจจุบันคือ Supabase
- ผู้สนับสนุนในอดีต ได้แก่ Crunchy Data, Resonate
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
แม้จะเคยมีการสนับสนุนจากบริษัท แต่ก็ยังต้องทุ่มเวลาช่วงกลางคืนและวันหยุดสุดสัปดาห์ลงไปด้วย และหลังจาก Crunchy Data ถูกขายไป เขาก็ยังคงดูแลต่อพร้อมกับพยายามหาตำแหน่งงานที่จะทำสิ่งนี้ต่อได้ แต่ก็ไม่สำเร็จ
เพื่อเลี้ยงชีพ เขาจำเป็นต้องมองหาโอกาสที่กว้างขึ้น ซึ่งนั่นหมายความว่าเขาไม่สามารถสละเวลาที่จำเป็นสำหรับการบำรุงรักษา แก้บั๊ก รีวิว PR และตอบสนอง issue ได้อีกต่อไป จึงตั้งใจจะ archive repository
คู่มืออยู่ที่ https://github.com/freakynit/postgre-backup-and-restore-guide และขอขอบคุณมากจริงๆ สำหรับเวลาและความพยายามทั้งหมดที่ทุ่มเทมา
แถมยังมีหลายคนที่เผาเงินไปกับโทเค็น ทำให้ทั้งเงินสำรองและเวลาก็ลดลงไปพร้อมกัน
ถ้านี่เป็นเครื่องมือระดับโปรดักชันที่มอบคุณค่าจริงในสภาพแวดล้อมเชิงพาณิชย์ ไม่ใช่แค่โปรเจกต์งานอดิเรก ก็ย่อมมีโอกาสที่บริษัทแสวงหากำไรจะเข้ามาเติมช่องว่างนี้
แต่ผู้ใช้งานก็ต้องกลายเป็นลูกค้าและจ่ายเงินจริง การส่ง bug report กับคำบ่นไปให้ผู้ดูแลที่ทำงานฟรีอยู่เรื่อยๆ นั้นไม่ยั่งยืน
เราต้องการแนวทางใหม่สำหรับ ความยั่งยืนทางการเงินของ FOSS และดูเหมือนว่าการบริจาคอย่างเดียวคงไม่พอ
ไม่ว่าจะเป็นร้านในชุมชนหรือโปรเจกต์โอเพนซอร์สก็เหมือนกัน
แต่สิทธิ์ลิขสิทธิ์อาจกระจายอยู่ในหมู่ผู้มีส่วนร่วมหลายคน จึงอาจต้องจัดการเรื่องสิทธิ์ตามว่ามี ACL หรือไม่และอยู่ภายใต้เขตอำนาจใด รวมถึงอาจต้องมีข้อตกลงเรื่องการแบ่งรายได้ด้วย
ตอนมีการสนับสนุนจากบริษัททุกอย่างยังเดินต่อได้ แต่พอบริษัทถูกขายและเจ้าของใหม่เปลี่ยนลำดับความสำคัญ เครื่องมือโครงสร้างพื้นฐานที่มี 3.8k ดาว ตัวนี้ก็เริ่มสั่นคลอนทันที ผู้ใช้หลายคนอาจไม่เคยรู้เลยว่าแหล่งทุนของเครื่องมือสำรองข้อมูลที่ตัวเองใช้ขึ้นอยู่กับกลยุทธ์ M&A ของคนอื่น
เพราะแบบนั้นฉันเองก็เริ่มค่อยๆ ย้ายไปใช้ไฟล์ที่ติดตามด้วย SQLite และ git มากขึ้น
เนื่องจากแม้แต่ managed Postgres stack ก็ยังวางอยู่บนเครื่องมือหลายตัวที่ดูแลโดยผู้คนซึ่งเราไม่รู้สถานะทางการเงินของพวกเขา
แต่ภาพใหญ่เรื่องโครงสร้างเงินทุนที่เปราะบางนั้นก็ยังเป็นประเด็นจริง
และในจังหวะเดียวกันก็ควรกลับไปดูโปรเจกต์ที่เราไม่อยากเสียไป แล้วตั้งค่าการสนับสนุนไว้ตั้งแต่ตอนนี้
ทุกคนบอกว่าเสียใจ แต่ถ้าเสียใจจริง ก็ควรถามตัวเองก่อนว่า เสียใจถึงขั้นพร้อมบริจาคไหม
โดยเฉพาะตรงที่มันไม่ได้จริงจังแค่เรื่อง backup แต่ยังรวมถึง การกู้คืนและการตรวจสอบความถูกต้อง ด้วย ซึ่งหาได้ยากมาก และฉันเองก็เคยเจอประสบการณ์แย่หนักในที่ทำงานเพราะละเลยเรื่องนี้
รายละเอียดอยู่ที่ https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
เลยรู้สึกว่านี่เป็นความสูญเสียที่ค่อนข้างใหญ่
เลยสงสัยว่าเมื่อเทียบกับ WAL-G หรือ Barman แล้วเป็นอย่างไร
https://github.com/wal-g/wal-g
https://github.com/EnterpriseDB/barman
ทุกคืนเราจะสร้าง nightly DB ที่กู้คืนจาก Barman แล้วเอาไปใช้ทั้งสำหรับฝึกอบรมผู้ใช้และทดสอบด้วย เพื่อยืนยันอย่างต่อเนื่องว่า backup ไม่ได้เสียจริงๆ และหลายปีก็ยังไม่มีปัญหา
หลังจากเงียบไปหลายปี ตอนนี้ฉันกลับมาทำฝั่ง managed Postgres อีกครั้ง และหวังว่านอกจาก delta backup ที่ wal-g มีผ่านการเปรียบเทียบบล็อกของตัวเองแล้ว มันจะรองรับ pg17 incremental backup ด้วย
แล้วก็ควรใช้ daemon mode จริงๆ
น่าเสียดายที่เครื่องมือคู่แข่งหายไป แต่พื้นที่นี้ยังมีอะไรให้พัฒนาอีกมาก และเวลาที่ Postgres อยากรันบนระบบที่ไม่มี overcommit นั้น C มีข้อได้เปรียบเหนือ Golang อยู่เหมือนกัน
ตอนประเมินเมื่อราว 9 ปีก่อน ฝั่งนี้ดึงดูดใจกว่า pgBackRest เพราะคุณสมบัติ streaming PITR
งั้นตอนนี้ทางเลือกที่ใกล้ที่สุดคือ wal-g, barman หรือ databasus กันแน่
ถึงจะพูดว่าตัวเองแค่เล่นบท DBA แต่จริงๆ แล้วการเลือกนี่สำคัญมาก
เผื่อเป็นข้อมูล ฉันทำงานเป็น DBRE
เอกสารที่เกี่ยวข้องคือ https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
https://github.com/aiven-open/pghoard ก็ดูน่าสนใจ แต่ฉันยังไม่ได้ลองพิสูจน์ด้วยตัวเอง
ยิ่งทำให้เรื่องนี้น่าเสียดายมากขึ้น และการหาทางเลือกที่ เทียบเท่าด้านฟังก์ชันการทำงาน กับเครื่องมือที่ยอดเยี่ยมนี้คงไม่ง่าย
ถ้าเป็นไปได้ก็หวังว่านี่จะเป็นการตัดสินใจที่ย้อนกลับได้ ไม่เช่นนั้นก็น่าจะมีทางให้โปรเจกต์ PostgreSQL รับมันเข้าไปใน contrib
ผู้เขียนเองก็คงอยากให้คนยังใช้มันต่อไป มากกว่าจะรีบทิ้งมันก่อนเวลาที่มันใช้งานไม่ได้จริงๆ
ไม่แน่ใจว่าจะต้อง fork หรือว่ายังสามารถเข้าไปเป็น contributor ใน repository เดิมแล้วรับช่วงต่อได้