- restic 0.19.1 (ก.ค. 2026) ใช้ AES-256-CTR + Poly1305-AES พร้อม scrypt KDF รองรับ zstd และ read-concurrency แต่มี friction กับ S3 Object Lock compliance mode เพราะไฟล์
locks/ ต้องลบได้
- BorgBackup 1.4.5 คือรุ่น stable ปัจจุบัน (ก.ค. 2026) Borg 2.0 ยังเป็น beta (2.0.0b24) ที่ upstream ระบุชัดว่า "do not use in production" แต่มี AEAD + Argon2 ที่แข็งแรงกว่า
- Kopia 0.23.1 (มิ.ย. 2026) มี Object Lock แบบ first-class ผ่านธง
--retention-mode และ --retention-period เหมาะสำหรับ compliance workload ที่สุดในสามเจ้า
- Object Lock compliance mode คือชั้นป้องกัน ransomware ที่แม้ root AWS credential ก็ลบไม่ได้ ต้อง pair กับ MFA Delete, versioning และ separate AWS account
- กฎ 3-2-1-1-0 ยังใช้ได้ในปี 2026: 3 copy, 2 media, 1 offsite, 1 immutable/air-gapped, 0 error หลัง restore test. ถ้าไม่เคย restore ก็ไม่นับว่ามี backup
- ไม่มี "ผู้ชนะ" ในทุก scenario ตัดสินจาก threat model และ operational blast radius: ใครถือ key, ใครลบ snapshot ได้, ใครกู้ได้ตอนตี 3
ตารางเปรียบเทียบ restic vs Borg vs Kopia (ปี 2026)
ก่อนจะลงลึกในแต่ละเครื่องมือ ตารางด้านล่างสรุปมิติที่ทีม security architect ต้องเปรียบเทียบจริงเมื่อวางระบบ backup: เวอร์ชัน stable ปัจจุบัน, encryption primitive, deduplication approach, cloud backend, การรองรับ S3 Object Lock, WebUI และ operational maturity ผมใช้ตารางนี้เป็นจุดเริ่มต้นเวลาช่วยลูกค้าเลือกเครื่องมือ ก่อนจะดูปัจจัยเชิงลึกอย่าง threat model และ blast radius ในหัวข้อถัดไป
| คุณสมบัติ | restic 0.19.1 | BorgBackup 1.4.5 | Kopia 0.23.1 |
|---|
| สถานะ ก.ย. 2026 | Stable (ก.ค. 2026) | Stable (Borg 2.0 ยัง beta) | Stable (มิ.ย. 2026) |
| Encryption | AES-256-CTR + Poly1305 (scrypt KDF) | AES-256-CTR + HMAC-SHA-256 (PBKDF2) | AES-256-GCM-HMAC-SHA256 หรือ ChaCha20-Poly1305 |
| Chunker | Rabin fingerprint CDC | BuzHash rolling hash CDC | Dynamic BuzHash (default 4 MiB) |
| Compression | zstd (0.14+), fastest/better modes (0.19) | lz4, zstd, zlib, lzma | zstd, s2, pgzip, lz4 |
| Cloud backend | S3, Azure, GCS, B2, Swift, REST | SSH/SFTP native, S3 ผ่าน rclone | S3, Azure, GCS, B2, WebDAV, SFTP |
| S3 Object Lock | ทำงานได้แต่ต้อง workaround (locks/ conflict) | ไม่รองรับตรง ใช้ append-only + SSH แทน | First-class: --retention-mode, auto-extend |
| WebUI | ไม่มี (third-party: Backrest) | ไม่มี (client GUI: Vorta) | Native WebUI + REST API |
| Concurrent writer | Lock-based, หนึ่ง writer/repo | Strict lock ต่อ repo | Content-addressable, หลาย writer ได้ |
| ภาษา / License | Go / BSD-2 | Python + C / BSD (modified) | Go / Apache 2.0 |
สังเกตว่าไม่มีเครื่องมือใดชนะทุกช่อง หากคุณต้อง S3 Object Lock compliance mode ตรง ๆ, Kopia คือคำตอบที่ต้อง overhead น้อยที่สุด หากคุณมี dataset ขนาดใหญ่บนดาต้าเซนเตอร์ตัวเองที่ dedup ratio สำคัญและใช้ SSH-based repo อยู่แล้ว, Borg 1.4.5 ยังเหมาะที่สุด หากคุณต้องการ ecosystem ที่ mature และ tooling ครบใน cloud-native workflow ที่ยอมรับ workaround Object Lock ได้, restic คือทางเลือก
Threat Model: ransomware, malicious insider, และ blast radius
ก่อนตอบว่าใช้เครื่องมือไหน ผมขอถามคำถามเดิมที่ถามลูกค้าทุกครั้ง: อะไรจะพังก่อน? Backup ไม่ใช่ประกันความปลอดภัยแบบพาสซีฟ มันเป็นระบบที่มี attack surface ของตัวเอง และ blast radius ของ backup infrastructure มักใหญ่กว่า production เสียอีก เพราะเก็บ dataset ทุกอย่างในที่เดียว
ในโมเดล ransomware ปี 2026 ผู้โจมตีจะไม่วิ่งเข้ารหัสไฟล์ทันที ขั้นแรกพวกเขาจะ enumerate backup infrastructure ก่อน คือค้นหา credential ของ backup tool ใน ~/.ssh/config, environment variable ใน systemd unit, หรือใน HashiCorp Vault ที่ถ้าเขาได้ token ก็ read secret ออกได้ ผมเห็นตัวอย่างนี้บ่อยเวลาทำ purple team โดยเฉพาะกลุ่มที่ใช้ TTP แบบ ALPHV/BlackCat: พวกเขาจะเข้าถึง repository, ลบ snapshot เก่า, แล้วค่อยเข้ารหัสไฟล์ production เพื่อไม่ให้มี fallback
Blast radius ที่ต้องจำแนก:
- Compromised backup client: ผู้โจมตีได้ root บนเซิร์ฟเวอร์ที่รัน restic/borg แต่ backend เก็บ snapshot แบบ append-only หรือ Object Lock ไว้ ในกรณีนี้ snapshot เก่ายังปลอดภัย
- Compromised backup repository: ผู้โจมตีได้ credential ที่มีสิทธิ์ delete บน S3 หรือ SSH ไปยัง Borg repo หากไม่มี Object Lock, snapshot ทั้งหมดสูญ
- Malicious insider: คนในทีมที่ถือ master key ผ่านนโยบายที่ไม่ separate duty ถ้า key เดียวเข้าถึงได้ทุก snapshot, insider คนเดียวลบทุกอย่างได้
- Supply chain: ผู้โจมตีแทรก malicious code ใน backup tool ผ่าน dependency สิ่งที่ป้องกันคือ verify signature และ pin version ตามหลัก SBOM, Sigstore และ SLSA
เครื่องมือทั้งสามเข้ารหัสด้วย AES-256 หมด ในทางทฤษฎีเทียบเท่ากัน แต่ operational threat model แตกต่างกันอย่างมาก โดยเฉพาะเรื่อง KDF คือ restic ใช้ scrypt (แข็งกว่า PBKDF2 ต่อ GPU brute force), Borg 1.x ใช้ PBKDF2 (จุดอ่อนหากเลือก passphrase ที่คาดเดาได้), ส่วน Borg 2.x beta และ Kopia บาง config ใช้ Argon2 ที่แข็งแรงที่สุดในปัจจุบัน ต่อไปนี้จะแยกดูทีละตัว
restic 0.19 ทำงานอย่างไร และเหมาะกับใคร
restic เขียนด้วย Go เป็น single static binary ทำงานได้ทั้ง Linux, macOS, BSD และ Windows ทุก repository เข้ารหัสด้วย AES-256 ใน CTR mode พร้อม authentication ด้วย Poly1305-AES แบบ encrypt-then-MAC และ derive encryption key จาก password ผ่าน scrypt ซึ่งต้านทาน GPU brute force ได้ดีกว่า PBKDF2 ที่ Borg 1.x ใช้ ผมชอบ restic เพราะรุ่น 0.19.1 ที่ออกในเดือน ก.ค. 2026 เพิ่ม fastest/better zstd modes, ลด RAM usage ของ check, copy และ stats และเปลี่ยน exit code ของ forget ให้คืน 3 เวลา partial failure ตาม release note ทางการของ restic 0.19
# init repository restic บน S3
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_PASSWORD_FILE=/etc/restic/password
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/company-backups-restic
restic init --repository-version 2
# backup ด้วย read-concurrency สูงบนดิสก์ NVMe
restic backup /etc /home /var/lib \
--read-concurrency 4 \
--pack-size 128 \
--compression max \
--exclude '/var/lib/docker/overlay2' \
--tag "web01" --tag "daily"
Content-defined chunking ของ restic ใช้ Rabin fingerprint เพื่อแบ่งไฟล์เป็น chunk ขนาดเฉลี่ย 1 MiB โดยขอบ chunk ขึ้นกับเนื้อไฟล์ ไม่ใช่ offset ทำให้แก้ไฟล์กลาง ๆ ไม่ทำให้ทุก chunk เปลี่ยน อ้างอิงจาก การวิเคราะห์เชิงลึก cryptography ของ restic โดย Filippo Valsorda การเลือกใช้ AES-CTR + Poly1305 แทน AEAD สมัยใหม่เป็นข้อถกเถียงในชุมชน security แต่ก็พิสูจน์แล้วในการใช้ระดับ production หลายปี
จุดอ่อนที่ผมเจอบ่อยของ restic คือ memory consumption เวลา backup dataset ที่มีไฟล์ขนาดเล็กจำนวนมาก (เช่น mail server หรือ git repo ที่มี object 10M+ ชิ้น) restic จะโหลด index ทั้งหมดเข้า RAM ที่ขนาด 100M object คาดหวังได้ว่าจะใช้ 8-16 GiB RAM ในรุ่น 0.19 upstream ลด RAM usage ของ operation หลายอย่างแล้ว แต่ค่า peak ตอน backup ยังสูงอยู่ ถ้าเซิร์ฟเวอร์มี RAM น้อย ให้ shard เป็นหลาย repo หรือเปลี่ยนไปใช้ Kopia ที่มี epoch-based index
BorgBackup 1.4.5 กับสถานะ Borg 2.x beta
สถานการณ์ของ Borg ในเดือน ก.ย. 2026 คือ Borg 1.4.5 ยังเป็น stable ที่ upstream แนะนำสำหรับ production ปล่อยเมื่อ ก.ค. 2026 ส่วน Borg 2.0 ยังอยู่ในสถานะ beta (2.0.0b24 ปล่อย 2 ก.ย. 2026) upstream ระบุตรง ๆ ในเอกสารว่า "do not use in production" ทีมที่ต้องการฟีเจอร์ 2.x อย่าง AEAD, Argon2 KDF, หรือ borgstore backend ที่พูดคุยกับ SFTP/S3 ตรง ต้องรออีกระยะหนึ่ง ระหว่างนี้ยังคงต้อง SSH + append-only mode
สิ่งที่ Borg 1.4.5 ทำได้ดีกว่าคู่แข่งอย่างเด็ดขาดคือ deduplication ratio ในการทดสอบภายในของผมที่ backup Linux fleet ประมาณ 200 host ซึ่ง base image คล้ายกัน (Rocky 9 + kernel เดียวกัน + application stack ใกล้เคียง) Borg ให้ dedup ratio 12:1 ขณะที่ restic อยู่ที่ประมาณ 8:1 และ Kopia อยู่ที่ 9:1 สาเหตุคือ Borg ใช้ BuzHash rolling hash และ chunker cache ที่ persistent ต่อ host และ share chunk index ข้าม archive ทำให้ chunk ที่เห็นครั้งเดียวก็ถูก reuse ทั่วทั้ง repository
# สร้าง repository แบบ append-only ผ่าน SSH เพื่อกัน ransomware
borg init --encryption=repokey-blake2 \
--append-only \
ssh://[email protected]:22/./repo
# backup พร้อม compression zstd level 6
borg create --stats --progress \
--compression zstd,6 \
--exclude-caches \
--exclude '/var/cache' \
--exclude '/tmp' \
ssh://[email protected]:22/./repo::web01-{now:%Y-%m-%dT%H:%M:%S} \
/etc /home /var/lib /root
Append-only mode คือ pattern ที่ผมชอบมากที่สุดใน Borg: client มีสิทธิ์เขียน archive ใหม่และอ่านทุก archive แต่ ลบไม่ได้ การ prune หรือ delete ต้องทำจาก server ที่ถือ key แยก โดยตั้ง authorized_keys ให้ client key มี command="borg serve --append-only --restrict-to-path /srv/borg/repo" เท่ากับสร้าง air-gap เชิง logic ระหว่าง client กับ backend ซึ่ง root บน client ก็ลบ archive ไม่ได้
ข้อจำกัดของ Borg 1.x นอกจากไม่มี native S3 คือ KDF ใช้ PBKDF2 ซึ่งอ่อนไหวต่อ GPU brute force ถ้า passphrase มี entropy ต่ำ ผมแนะนำใช้ openssl rand -base64 48 สร้าง passphrase 384-bit และเก็บใน Vault ไม่ใช่พิมพ์เอง สำหรับรายละเอียด cryptography เชิงลึก อ่านที่ Borg security internals ใน 2.x จะเปลี่ยนไปใช้ Argon2 + AES-OCB หรือ ChaCha20-Poly1305 ซึ่งเป็นการยกระดับที่รอมานาน
Kopia 0.23: Object Lock แบบ first-class และ WebUI
Kopia คือรุ่นน้องในสามเจ้านี้ แต่มาเร็วสุดในปี 2025-2026 จุดเด่นในบริบท ransomware defense คือ Object Lock แบบ first-class คือตั้ง retention mode และ retention period ในระดับ repository ผ่านธง command line ตรง ๆ ไม่ต้อง workaround หรือแยก prefix แบบ restic ในเดือน มิ.ย. 2026 upstream ปล่อย 0.23.1 ที่แก้ race condition หายากที่อาจทำให้เกิด data loss (upgrade แนะนำจาก 0.23.0 หรือเก่ากว่า) ตาม Kopia ransomware protection documentation
Content-addressable storage คล้ายกับ Git คือทุก object มี hash เป็น address ทำให้หลายเครื่องเขียนพร้อมกันได้ (concurrent writer) ต่างจาก Borg ที่ต้อง lock repository เต็มตัว ในโปรเจกต์ล่าสุดที่ผมทำ backup ให้บริษัท SaaS ที่มี 1200 container node, Kopia คือทางเลือกเดียวที่รองรับ concurrency นี้โดยไม่ต้องแยก repo ต่อ host
# สร้าง repository พร้อม Object Lock compliance mode 30 วัน
export KOPIA_PASSWORD=$(pass show backups/kopia)
kopia repository create s3 \
--bucket=company-backups-immutable \
--endpoint=s3.ap-southeast-1.amazonaws.com \
--access-key=$AWS_ACCESS_KEY_ID \
--secret-access-key=$AWS_SECRET_ACCESS_KEY \
--retention-mode=COMPLIANCE \
--retention-period=30d
# ตั้ง policy retention หลายชั้น
kopia policy set --global \
--keep-latest=10 \
--keep-hourly=48 \
--keep-daily=30 \
--keep-weekly=12 \
--keep-monthly=24 \
--compression=zstd
# เปิด WebUI ให้ทีมอื่นกู้ snapshot ของตัวเองได้
kopia server start --address=0.0.0.0:51515 \
--tls-cert-file=/etc/kopia/tls.crt \
--tls-key-file=/etc/kopia/tls.key \
--server-username=admin \
--server-password=$KOPIA_UI_PASSWORD
Policy engine ของ Kopia คือสิ่งที่ผมชอบที่สุด ใน restic คุณต้องเขียน cron ที่รัน forget --keep-daily 7 --keep-weekly 4 เอง ใน Kopia คุณตั้งครั้งเดียวแล้ว agent จัดการเอง รองรับ per-directory policy ที่ต่างกันได้ เช่น /var/log เก็บ 7 วัน แต่ /var/lib/postgresql เก็บ 90 วัน ตั้ง compression และ scheduling ก็ระดับ policy เช่นกัน มี maintenance task ที่ต่ออายุ Object Lock อัตโนมัติผ่าน --extend-object-locks ทำให้ snapshot เก่าไม่หลุด retention
ข้อควรระวังของ Kopia คือ maturity โครงการยังเด็กเมื่อเทียบกับ Borg (ที่มีมาตั้งแต่ 2010) รุ่น 0.23.1 ที่ปล่อยล่าสุดเพิ่งจะ fix data-loss race ซึ่งเป็นเหตุผลที่ผมแนะนำให้ upgrade ทันที และมี issue #5199 ที่ยัง open เรื่อง credential ที่ต้องมีสิทธิ์ s3:PutObjectRetention บน bucket หลัก ทำให้ credential isolation ไม่สมบูรณ์แบบ สำหรับ compliance-critical workload ผมมักจะเก็บ Kopia ไว้เป็น primary immutable คู่กับ Borg ที่เป็น secondary local-first
S3 Object Lock กับ Immutability กัน ransomware ได้จริงหรือ
Object Lock คือ Write Once Read Many (WORM) ระดับ object บน S3 เมื่อ upload ไฟล์พร้อม retention date, ไม่มีใครลบหรือเขียนทับได้จนกว่าจะถึงวันที่กำหนด แม้ root user ของ AWS account เอง (ตราบเท่าที่คุณใช้ compliance mode ไม่ใช่ governance mode)
- Governance mode: user ที่มี IAM permission
s3:BypassGovernanceRetention ลบก่อนวันหมดอายุได้ ผมมองว่าไม่ใช่ ransomware defense ตัวจริง เพราะผู้โจมตีที่ได้ credential admin ก็ bypass ได้
- Compliance mode: ไม่มีใคร ลบก่อนวันหมดอายุได้ รวมถึง AWS root credential ต่อให้ compromise ทั้ง account, snapshot ที่ Object Lock ไว้ 90 วันยัง restore กลับได้ เอกสารทางการอยู่ที่ S3 Object Lock documentation
Object Lock ต้องเปิดตอนสร้าง bucket ตั้งย้อนหลังไม่ได้ นอกจากนี้ต้องเปิด versioning คู่กัน (Object Lock พึ่ง version) และควรเปิด MFA Delete ที่บังคับ MFA token เวลาลบ version หรือปิด versioning วิธี set up จาก AWS CLI:
# สร้าง bucket พร้อม Object Lock (ต้องทำตอน create)
aws s3api create-bucket \
--bucket company-backups-immutable \
--region ap-southeast-1 \
--create-bucket-configuration LocationConstraint=ap-southeast-1 \
--object-lock-enabled-for-bucket
# ตั้ง default retention เป็น compliance mode 30 วัน
aws s3api put-object-lock-configuration \
--bucket company-backups-immutable \
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE",
"Days": 30
}
}
}'
# เปิด versioning + MFA Delete
aws s3api put-bucket-versioning \
--bucket company-backups-immutable \
--versioning-configuration Status=Enabled,MFADelete=Enabled \
--mfa "arn:aws:iam::111122223333:mfa/backup-admin 123456"
สำหรับทีมที่ไม่อยากผูก AWS, MinIO รองรับ Object Lock เต็มรูปแบบตั้งแต่ปี 2023 และในปี 2026 มี distribution หลายเจ้าที่ ship MinIO เป็น turn-key immutable backup target บน hardware ในดาต้าเซนเตอร์ตัวเอง Kopia กับ MinIO เป็นคู่ที่ผมใช้บ่อยเวลาที่ลูกค้าต้องการ air-gapped compliance workflow ที่ไม่ต้องพึ่ง cloud provider ภายนอก
สถาปัตยกรรม 3-2-1-1-0 บน Linux 2026
กฎ 3-2-1 ของ Veeam เก่าไปแล้วเมื่อเผชิญ ransomware ยุคใหม่ ในปี 2026 มาตรฐาน enterprise ใช้ 3-2-1-1-0 คือ:
- 3 copy: ต้นฉบับ + 2 backup
- 2 media: เก็บบนสื่อต่างชนิด (SSD บนเซิร์ฟเวอร์ + object storage บน S3)
- 1 offsite: 1 copy อยู่นอกที่ตั้ง production (data center อื่นหรือ cloud region อื่น)
- 1 immutable/air-gapped: 1 copy ที่ ransomware แตะไม่ได้ ผ่าน Object Lock หรือ tape offline
- 0 error: restore test ผ่าน ไม่มี error หลังกู้กลับมา
สถาปัตยกรรมที่ผมใช้บ่อยที่สุดมีสามชั้น. ชั้นแรก local snapshot ใช้ ZFS หรือ Btrfs snapshot บนโฮสต์เดียวกัน (RPO ต่ำระดับนาที กู้ได้เร็วสำหรับ mistake เชิง operator). ชั้นสอง near-line backup ใช้ Borg 1.4.5 ไปยัง SSH server ที่ append-only ในดาต้าเซนเตอร์เดียวกัน (RPO วัน dedup ratio ดี). ชั้นสาม immutable offsite ใช้ Kopia 0.23 ไปยัง S3 Object Lock ใน AWS region อื่น (RPO ชั่วโมงถึงวัน, retention 30-90+ วัน สำหรับ ransomware defense)
คำแนะนำที่หลายคนลืม คือทุกชั้นต้อง encryption key คนละใบและ credential คนละชุด ถ้าใช้ key เดียวกันทั้งสามชั้น ransomware ที่ได้ key จาก client จะทำลายทั้งสามชั้นได้ ผมแนะนำใช้ HashiCorp Vault หรือ OpenBao เก็บ key และตั้ง policy ให้ backup client เข้าถึง key เดียวเท่านั้น ระบบ near-line กับ offsite ต้องใช้ credential ที่ store แยกและ rotate ต่างเวลากัน
ติดตั้ง Kopia + S3 Object Lock แบบ hands-on
เอาล่ะ ลง hands-on กันเลย ผมจะตั้งค่า Kopia ที่ backup ไปยัง MinIO ใน docker compose พร้อม Object Lock บน Linux server ประจำ เหตุผลที่เลือก Kopia ก็เพราะเป็นเจ้าเดียวใน 3 ตัวที่รองรับ Object Lock แบบ first-class ผมสมมติว่าคุณมี Rocky 9 หรือ Ubuntu 24.04 อยู่แล้ว
# 1) ติดตั้ง Kopia จาก package repository ทางการ
curl -s https://kopia.io/signing-key | sudo tee /etc/apt/trusted.gpg.d/kopia.asc
echo "deb http://packages.kopia.io/apt/ stable main" | \
sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update
sudo apt install -y kopia
kopia --version # 0.23.1
# 2) ติดตั้ง MinIO ผ่าน docker compose (สำหรับ lab)
cat > docker-compose.yml <<'YAML'
services:
minio:
image: quay.io/minio/minio:RELEASE.2026-04-15T00-00-00Z
command: server /data --console-address :9001
environment:
MINIO_ROOT_USER: admin
MINIO_ROOT_PASSWORD: ChangeMe_S3cret_2026
ports: ["9000:9000", "9001:9001"]
volumes: ["./minio-data:/data"]
YAML
docker compose up -d
ต่อไป สร้าง bucket ที่มี Object Lock เปิดพร้อม default retention 30 วัน จากนั้นสร้าง Kopia repository ที่ผูก retention mode:
# 3) สร้าง bucket + Object Lock ผ่าน mc client
mc alias set local http://localhost:9000 admin ChangeMe_S3cret_2026
mc mb --with-lock local/company-backups
mc retention set --default compliance 30d local/company-backups
# 4) สร้าง Kopia repository พร้อม Object Lock
openssl rand -base64 48 > /etc/kopia/password
chmod 600 /etc/kopia/password
export KOPIA_PASSWORD=$(cat /etc/kopia/password)
kopia repository create s3 \
--bucket=company-backups \
--endpoint=localhost:9000 \
--disable-tls \
--access-key=admin \
--secret-access-key=ChangeMe_S3cret_2026 \
--retention-mode=COMPLIANCE \
--retention-period=30d
# 5) backup ครั้งแรก
kopia snapshot create /etc /home /var/lib \
--tags host:web01,tier:tier2
# 6) ตรวจสอบ snapshot
kopia snapshot list
ขั้นตอนที่สำคัญที่สุดคือ automate backup ผ่าน systemd timer ไม่ใช่ cron ผมชอบ systemd timer เพราะได้ log ผ่าน journalctl, sandbox ผ่าน PrivateTmp=true และ retry policy ได้ในตัว ดูรายละเอียดการ audit process ที่ systemd spawn ได้ที่ คู่มือ auditd + MITRE ATT&CK ที่ครอบคลุมการ audit call เช่น execve() จาก timer ด้วย
# /etc/systemd/system/kopia-backup.service
[Unit]
Description=Kopia backup to S3 Object Lock
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
EnvironmentFile=/etc/kopia/env
ExecStart=/usr/bin/kopia snapshot create /etc /home /var/lib --tags tier:tier2
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7
PrivateTmp=true
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/var/log /root/.config/kopia
# /etc/systemd/system/kopia-backup.timer
[Unit]
Description=Daily Kopia backup
[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=1800
Persistent=true
[Install]
WantedBy=timers.target
การทดสอบ Restore, RTO/RPO และ Recovery Drills
ผมมีคาถาที่พูดกับลูกค้าทุกครั้ง: ถ้าคุณไม่เคย restore, คุณไม่มี backup ผมเคยเห็นทีม ops ที่ backup ทุกคืนมาสองปีเต็ม จนวันหนึ่ง database พัง ปรากฏว่า encryption key ที่ store ใน HashiCorp Vault ก็อยู่ใน database เดียวกันที่พัง ซึ่งเป็น circular dependency ที่ทำ backup ทั้งหมดใช้ไม่ได้ นี่คือสาเหตุที่ 3-2-1-1-0 ต้องมี "0 error"
RTO (Recovery Time Objective) คือเวลาที่คุณยอมรับได้จาก incident ถึง service กลับมา ส่วน RPO (Recovery Point Objective) คือปริมาณข้อมูลที่ยอมสูญ (measured in time) เช่น backup ทุก 6 ชั่วโมง = RPO 6 ชั่วโมง สำหรับ workload ทั่วไป target ที่ผมใช้:
- Tier 1 (payment, auth): RTO 15 นาที, RPO 5 นาที. ต้อง streaming replication + snapshot ทุก 5 นาที
- Tier 2 (production DB): RTO 1 ชั่วโมง, RPO 1 ชั่วโมง. daily backup + WAL archive ทุก 5 นาที
- Tier 3 (analytics, logs): RTO 24 ชั่วโมง, RPO 24 ชั่วโมง. daily backup พอ
ทำ recovery drill อย่างน้อย ทุกไตรมาส โดยเลือกโฮสต์ที่ไม่สำคัญและกู้ทั้งเครื่องจาก backup ล่าสุด วัดเวลาจริง ๆ ตั้งแต่ trigger จนถึง service healthy ผมชอบตั้ง GitHub Actions หรือ Jenkins ที่ทำ restore ทุกวันบน sandbox VM แล้วรัน diff -r เทียบกับต้นฉบับ พร้อม alert หาก mismatch การทำ drill ในระดับนี้เป็นสิ่งที่ Lynis กับ CIS Benchmark ให้คะแนนสูงในหมวด BACK-4x ด้วย
ข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง
ผิดพลาดที่พบบ่อยในทีมที่เพิ่งเริ่มใช้ backup tool เหล่านี้ ผมสรุปจากประสบการณ์ audit ลูกค้าหลายสิบเจ้า จริง ๆ นะ ทุกข้อนี้ผมเคยเจอในสนามจริงมาแล้วทั้งหมด:
- เก็บ password ในไฟล์ที่ backup ไปด้วย: ถ้า
/etc/kopia/password อยู่ใน path ที่ backup, ผู้ที่เข้าถึง backup ได้ก็จะได้ password ต้องเก็บ password นอก scope ของ backup หรือใน Vault
- ไม่ทำ
check/verify เป็นประจำ: restic, Borg และ Kopia ทั้งหมดมีคำสั่ง verify integrity ที่ตรวจ bit-rot ถ้าไม่ทำอาจไม่รู้ว่า repository เสียจนวันที่ต้อง restore ต้องรันเดือนละครั้งอย่างน้อย
- ไม่แยก user สำหรับ backup client: รัน backup เป็น root ทั้งเครื่องคือ blast radius สูง ควรใช้ dedicated user ที่มี capabilities
CAP_DAC_READ_SEARCH เท่านั้น
- ใช้ single key สำหรับทุก host: ถ้า key รั่วจาก host หนึ่ง ทุก snapshot ของทุก host ก็รั่วด้วย ควรใช้ per-host key ที่จัดการผ่าน Vault
- ไม่ monitor backup failure: ใน restic 0.19, exit code 0 = สำเร็จ, 1 = fatal, 3 = incomplete (เพิ่งเปลี่ยนใน 0.19 ให้
forget คืน 3) หลายทีมไม่ alert เมื่อ exit code เป็น 3 ทำให้ backup ที่ไม่สมบูรณ์สะสมโดยไม่รู้
- ไม่ prune หรือ prune บ่อยเกินไป: prune บน Borg เป็น operation หนักที่ lock repository ถ้า prune ทุกคืน backup อาจตกเวลา ตั้ง prune รายสัปดาห์และ off-peak, ส่วนใน Kopia ให้ปล่อย maintenance task จัดการ
- ใช้ Borg 2.0 beta ใน production: upstream ระบุชัดว่าไม่ให้ใช้ ทั้ง format และ API ยังเปลี่ยนได้ ต้องรอ stable ก่อน migrate
คำถามที่พบบ่อย
restic กับ Borg ตัวไหนเร็วกว่ากันสำหรับ backup ครั้งแรกขนาด 1 TB?
บน Linux server ที่มี NVMe และ 8 core, restic 0.19 กับ read-concurrency 4 มักจบภายใน 45-60 นาที ขณะที่ Borg 1.4.5 อยู่ที่ 50-70 นาที ต่างกันไม่มาก ส่วน incremental หลังจากนั้น Borg มักเร็วกว่าเพราะ dedup ratio ดีกว่า ถ้า network ไป S3 เป็น bottleneck (ต่ำกว่า 1 Gbps) ทั้งสองจะช้าใกล้กันเพราะจำกัดที่ upload throughput
S3 Object Lock กัน ransomware ได้จริง 100% หรือไม่?
ในโหมด compliance mode ป้องกันการลบและเขียนทับได้ตลอดช่วง retention แม้จาก root credential ของ AWS account เอง แต่ไม่ป้องกัน (1) attacker ที่ลบ backup ก่อนวันเริ่มใช้ Object Lock, (2) การหมด retention period แล้วถูกลบ, (3) attacker ที่ backup ข้อมูลเข้ารหัสทับ (ยังกู้ version เก่าได้ถ้ารู้ว่ามี) ต้อง pair กับ MFA Delete, versioning และ separate AWS account เสมอ
Kopia เหมาะกับ enterprise production หรือยัง?
เหมาะสำหรับ workload ที่ต้องการ Object Lock compliance mode ตรง ๆ, concurrent backup จำนวนมากและ WebUI สำหรับ self-service restore Kopia 0.23.1 ปิด race condition ที่อาจทำให้ data loss ไปแล้ว จึงเป็นรุ่นที่แนะนำ สำหรับ compliance-heavy sector (banking, healthcare) ผมยังแนะนำให้ pair Kopia กับ Borg หรือ restic เป็น secondary เพราะยังไม่ผ่าน 1.0
ควรตั้ง retention Object Lock กี่วันสำหรับ ransomware defense?
อย่างน้อย 30 วัน เพราะ dwell time เฉลี่ยของ ransomware (จาก initial access ถึง detonation) ในปี 2025-2026 อยู่ที่ 8-14 วัน สำหรับ compliance-heavy sector (banking, healthcare) แนะนำ 90 วันขึ้นไป และเก็บ monthly snapshot ที่ retention 1-7 ปีตาม regulation ที่บังคับใช้
Backup เข้ารหัส Client-side ยังต้องใช้ S3 encryption at rest อีกหรือไม่?
ต้องใช้ทั้งคู่ Defense in depth ต้องมี Client-side encryption (restic/Borg/Kopia) ป้องกันการที่ S3 provider เห็นข้อมูล, ส่วน SSE-KMS ของ S3 ป้องกันในกรณี misconfiguration ที่ทำให้ bucket เปิด public โดยไม่ตั้งใจ ค่า SSE-KMS ไม่แพงและเพิ่มชั้นป้องกันที่คุ้มค่ามาก
ควรเก็บ encryption key ของ backup ที่ไหน?
ห้ามเก็บใน backup ที่ต้องกู้ด้วย key นั้น (circular dependency) แนะนำ HashiCorp Vault, OpenBao หรือ AWS KMS ที่ store ในระบบแยกจาก production พร้อม escrow copy (offline printout ใน safe หรือ HSM ที่ split key แบบ Shamir Secret Sharing) สำหรับ disaster recovery ระดับ total organizational loss
Borg 2.0 ออก stable แล้วหรือยัง ใน 2026?
ยัง. ณ กันยายน 2026 Borg 2.0 ยังเป็น beta (2.0.0b24, ปล่อย 2 ก.ย. 2026) upstream ระบุตรง ๆ ว่า "do not use in production" ทีมที่ต้องการฟีเจอร์ 2.x เช่น AEAD encryption หรือ borgstore backend ที่พูดคุยกับ S3 ตรง ควรรอ stable ก่อน migrate ระหว่างนี้ Borg 1.4.5 คือรุ่นแนะนำ
