Lastsafe · Air-gap Server & Fast Recovery

ภาพรวมระบบ

Dashboard เดียวเห็นทุกอย่าง · จาก source ที่กำลังถูก backup · ไปจนถึง offsite copy ที่ปลายทาง

ฟีเจอร์ทั้งหมด

หลักการสำคัญในการออกแบบ Lastsafe · isolation · immutability · และความสามารถในการกู้ระบบกลับมาทำงานโดยไม่ต้องรอ restore เสร็จ

Air-gapped Backup Server Architecture

Lastsafe ได้รับการออกแบบให้ทำงานอยู่ในโซนเครือข่ายที่แยกออกจากระบบ Production Network เพื่อลดความเสี่ยงจากการเข้าถึงโดยตรงจากระบบต้นทาง โดยไม่มีบริการใดเปิดรับการเขียนข้อมูลจาก Source เข้าสู่ระบบสำรองข้อมูลโดยตรง

กระบวนการสำรองข้อมูลของ Lastsafe ใช้รูปแบบ Pull-based Backup โดย Lastsafe จะเป็นฝ่ายเริ่มต้นการเชื่อมต่อออกไปยังระบบต้นทาง เพื่อดึงข้อมูลตามรอบเวลาที่กำหนดไว้ แทนการเปิดช่องทางให้ระบบต้นทางส่งข้อมูลเข้ามาเอง

นอกจากนี้ Lastsafe ยังมีชั้นควบคุมแบบ Append-only Proxy คั่นระหว่าง Backup Engine และ Repository เพื่อบังคับให้งานสำรองข้อมูลสามารถเพิ่ม Snapshot ใหม่ได้เท่านั้น โดย Snapshot ที่ถูกบันทึกแล้วจะไม่สามารถถูกลบหรือแก้ไขย้อนหลังได้ภายในระยะเวลา Retention ที่กำหนด ช่วยเพิ่มความมั่นคงปลอดภัยของข้อมูลสำรองจากภัยคุกคาม เช่น Ransomware การลบข้อมูลโดยไม่ได้รับอนุญาต หรือการแก้ไขข้อมูลย้อนหลังโดยผู้ไม่ประสงค์ดี

ในระบบจริง · หน้า Security

Security page · Immutability Layers + Threat-model notes

Immutability Layers · 5 ชั้น (restic append-only · ZFS snapshot lock · Object Lock · off-platform copy · PQC signature)
Threat-model notes · ระบุชัดว่า vault เป็น Pull-only · sources ไม่มี credential ที่จะเขียนเข้า repo
Hardening checklist · ตรวจ append-only proxy reachable, off-site replication, password file permission

Incremental forever backup

หลังการสำรองข้อมูลครั้งแรก (full backup) Lastsafe จะเก็บเฉพาะ block ที่มีการเปลี่ยนแปลงในการ backup รอบถัด ๆ ไป โดยไม่จำเป็นต้องตั้งตารางทำ full backup ซ้ำเป็นรอบเหมือนรูปแบบ Grandfather-Father-Son ดั้งเดิม · ทุก snapshot ที่ปรากฏในระบบเป็น restore point ที่ใช้กู้คืนได้ทันทีโดยไม่ต้องไล่ทำ chain replay

ทุก block ที่ Lastsafe เขียนเข้า Repository ผ่านกระบวนการ Deduplicate และ Compress ที่ระดับ block ก่อนเขียน · block ที่มีเนื้อหาเหมือนกันระหว่าง Source หรือระหว่าง Snapshot ถูกเก็บเพียงครั้งเดียว · ทำให้การเก็บ Snapshot จำนวนมากของข้อมูลเดิมไม่กินพื้นที่เพิ่มเป็นทวีคูณ · เหมาะกับ workload ที่มี delta เล็กในแต่ละวัน เช่น Database, Mail store, File server

Retention Policy (กำหนดเก็บกี่วัน · เดือน · ปี) ถูกบังคับโดยระบบผ่านการเรียก forget ตามตารางที่ตั้งไว้ · ไม่ต้องเขียน script ภายนอกหรือ cron แยกเพื่อจัดการ retention · snapshot ที่อยู่ในช่วง retention อยู่ภายใต้การคุ้มครองของ Append-only Proxy เดียวกัน · ผู้ดูแลระบบไม่สามารถลบทิ้งโดยพลการก่อนถึงระยะเวลา Retention ที่กำหนดได้

ในระบบจริง · หน้า Snapshots

นับจำนวน Snapshot · "65 snapshots in the local repo" · สะสมขึ้นเรื่อย ๆ โดยไม่ต้องทำ full backup ใหม่
ข้อความ "Snapshots are immutable" · restore เปิดเป็น job ใหม่ · ไม่เคยเขียนทับ repo
รายการ Snapshot · แต่ละชุดเป็น restore point อิสระ · กู้คืนได้ทันทีโดยไม่ต้องไล่ replay incremental chain

Live Restore

เมื่อ production VM ล่ม · Lastsafe เปิด disk ของ snapshot ผ่าน qemu-nbd ให้ hypervisor อีกเครื่อง boot VM อ่าน block จาก vault โดยตรง · ระหว่างที่ service กลับมาทำงาน · background blockcopy ย้ายข้อมูลไป production storage แล้ว pivot ออกจาก NBD · ไม่ต้องรอ restore full image กลับก่อน boot

ดูขั้นตอนการทำงาน →

Ransomware & Lateral movement protection

Repository เป็น append-only ผ่าน restic REST proxy · process ที่ใช้ agent password เขียนได้ แต่ลบ/แก้ snapshot ย้อนหลังไม่ได้ · forget/prune ต้องใช้ owner password ที่แยกออกไปอีกชั้น · Credential ที่ Lastsafe ใช้กับ source เก็บไว้ที่ฝั่ง Lastsafe ไม่ใช่ที่ source · เมื่อ source โดน ransomware การโจมตีข้ามมายัง vault ทำได้ยากเพราะ source ไม่มีสิทธิ์เขียนเข้า repo

สำหรับ Offsite copy · เมื่อเปิด Immutability ที่หน้า Off-site · Lastsafe เรียก S3 PutObjectLockConfiguration (ผ่าน boto3) ตั้ง default retention บน bucket อัตโนมัติ · ทำงานกับ S3-compatible (AWS S3 · Backblaze B2 S3 API · Wasabi · MinIO) · เมื่อ bucket อยู่ในโหมด compliance · object ที่อยู่ในช่วง retention ไม่สามารถถูกลบได้แม้แต่โดย root credential ของบัญชีนั้น

Namespace isolation

Admin กำหนดได้ว่าผู้ใช้ระดับ Worker จะมองเห็น source ใดบ้าง · เมื่อ Worker เข้าหน้าเว็บ · ทุก route หลัก (Dashboard · Sources · Snapshots · Jobs · Recovery · Live Restore · Browse) แสดงเฉพาะ source/snapshot/job ของ source ที่ตัวเองได้รับมอบหมาย · การกระทำที่เขียนเปลี่ยนข้อมูล (Backup now · Restore · DR drill · Live restore publish/boot/migrate/promote) ถูกบล็อกด้วย HTTP 403 ถ้าไม่ได้รับสิทธิ์ · การสร้าง/ลบ/แก้ตาราง source ยังคงเป็นสิทธิ์ของ admin เท่านั้น

การ assign จัดการที่หน้า Users · ใช้ตาราง user_sources ใน sqlite ของระบบ · ลด blast radius เมื่อ credential ของ Worker หลุด · เหมาะกับ MSP ที่ host backup ของหลายลูกค้าบนเครื่องเดียวกัน หรือองค์กรที่แยกทีม IT ตาม business unit

เทคโนโลยีที่ใช้

เลือกใช้เทคโนโลยีและองค์ประกอบที่สามารถตรวจสอบได้ โปร่งใส และไม่ผูกติดกับผู้ผลิตรายใดรายหนึ่ง ลดความเสี่ยงจาก Vendor Lock-in พร้อมเปิดเผย Log และข้อมูลการทำงานที่จำเป็น เพื่อให้ทีมปฏิบัติการสามารถตรวจสอบ วิเคราะห์ และบริหารจัดการระบบได้อย่างมั่นใจ

Block-level dedup + FUSE

Backup engine ที่ deduplicate และ encrypt ที่ระดับ block · mount snapshot ออกมาดูได้เหมือน filesystem ปกติ

Live Restore (qemu-nbd + libvirt)

Boot VM โดยอ่าน disk จาก snapshot ใน vault ผ่าน qemu-nbd · ระหว่างนั้น background blockcopy ย้ายข้อมูลไปยัง production storage โดยไม่ต้องหยุดเครื่อง · ดูขั้นตอนการทำงาน

End-to-end encryption

เข้ารหัสที่ระดับ block ก่อนเขียน · key custody แยกจาก data plane · TLS ระหว่าง agent กับ server

3-2-1 backup rule

3 สำเนา · 2 ประเภท media · 1 สำเนา offsite · ระบบบังคับให้ครบและเตือนเมื่อขาด

Offsite transport + Object Lock

Offsite replication ไปยัง S3 compatible storage · WORM/Object Lock compliance หรือ governance mode

FastAPI + HTMX + Alpine.js

หน้าเว็บ server-rendered · interactive แบบ no-build · ทำงานได้ใน air-gap environment

systemd + append-only proxy

Service อยู่ใน systemd · เขียน repository ผ่าน append-only proxy เพื่อกัน ransomware

Live Restore · บูต VM จาก vault โดยตรง

เมื่อระบบ production ล่ม · Lastsafe เปิด snapshot ของ VM ผ่าน qemu-nbd ให้ hypervisor อีกเครื่องบูตอ่าน disk จาก vault ได้โดยไม่ต้องรอ copy ข้อมูลกลับมาก่อน · ระหว่างที่ VM ทำงาน background blockcopy จะย้ายข้อมูลไปยัง production storage แล้วค่อย pivot ออกจาก NBD เมื่อย้ายเสร็จ

Step 1 · publish

เลือก snapshot ที่ต้องการกู้คืน · ระบบ mount ผ่าน FUSE และเปิด disks/vda.raw ออกทาง qemu-nbd บน port pool ที่กำหนด · default read-only · เปิด TLS-PSK ได้ถ้าต้องการ

Step 2 · boot VM

Recovery host รัน virsh define + virsh start โดย disk source ใน domain XML ชี้ไปยัง NBD URI ของ Lastsafe · VM บูตอ่าน block จาก vault โดยตรง · service กลับมาให้ใช้งานในเวลาเป็นวินาที ไม่ต้องรอ copy ข้อมูลทั้งหมดกลับมา

Step 3 · migrate & pivot

ระหว่างที่ VM ทำงาน · virsh blockcopy สำเนา block ลง production storage ในเบื้องหลัง · เมื่อข้อมูลครบ ระบบ pivot disk จาก NBD ไปยัง qcow2 บน production และ detach publication ออก · VM ทำงานต่อบน storage จริง

การติดต่อ

สนใจ proof-of-concept · onboarding · หรือสอบถามรายละเอียดเพิ่มเติม ติดต่อตัวแทนจัดจำหน่ายและบริการได้ที่

Distributor & Onboarding Partner

Tunable Project

web.tunableproject.com · ทีมที่ดูแลการติดตั้ง · onboarding · และ support ของ Lastsafe ในประเทศไทย

→

Air-gap backup server เพื่อป้องกัน Ransomware และภัยที่ไม่คาดคิด