ทำไม Cloud Backup ถึงแตกต่างจาก On-Premise Backup
การ Backup ข้อมูลใน Cloud Environment แตกต่างจากการ Backup แบบ On-Premise อย่างมาก ในยุคที่องค์กรจำนวนมากย้าย Workload ไปยัง Cloud ไม่ว่าจะเป็น AWS, Microsoft Azure หรือ Google Cloud Platform (GCP) การเข้าใจความแตกต่างนี้เป็นสิ่งจำเป็นสำหรับ IT Admin ทุกคน ใน On-Premise Environment เราเป็นเจ้าของ Infrastructure ทั้งหมด ตั้งแต่ Server, Storage, Network ไปจนถึง Backup Hardware เราควบคุมทุกอย่างได้ 100 เปอร์เซ็นต์ เราเลือก Backup Software เอง กำหนด Backup Schedule เอง เก็บ Backup Tape หรือ Disk เอง แต่ใน Cloud ทุกอย่างเปลี่ยนไป Infrastructure เป็นของ Cloud Provider เราไม่สามารถเข้าถึง Physical Hardware ได้ Storage มีหลาย Tier แต่ละ Tier มีราคาและ Performance ต่างกัน Service แต่ละตัวมีวิธี Backup ที่แตกต่างกัน ค่าใช้จ่ายขึ้นอยู่กับปริมาณข้อมูล จำนวน Request และ Data Transfer
ใน On-Premise เรามักใช้ Backup Software ตัวเดียว เช่น Veeam, Commvault, Veritas NetBackup สำหรับ Backup ทุกอย่าง ทั้ง Server, Database, File Share, Application แต่ใน Cloud แต่ละ Service มี Native Backup Feature ของตัวเอง เช่น AWS RDS มี Automated Backup ในตัว Azure VM มี Azure Backup Service GCP Cloud SQL มี Automated Backup ในตัว การใช้ Native Backup Feature มีข้อดีคือ Integrate ได้ดี ไม่ต้องติดตั้ง Agent เพิ่ม แต่ข้อเสียคือถ้าใช้ Multi-Cloud จะมี Backup Tool หลายตัวที่ต้อง Manage แยกกัน ไม่มี Central Management
อีกความแตกต่างที่สำคัญคือ Cost Model ใน On-Premise ค่า Backup เป็น CAPEX (Capital Expenditure) ที่ลงทุนซื้อ Hardware และ Software License ครั้งเดียว แล้ว Depreciate ไปหลายปี แต่ใน Cloud ค่า Backup เป็น OPEX (Operating Expenditure) ที่จ่ายตามปริมาณที่ใช้ทุกเดือน ถ้าไม่ Manage ดี ค่า Cloud Backup อาจสูงกว่าที่คาดมาก โดยเฉพาะ Data Transfer Cost ที่ถูก Charge เมื่อ Download Backup ออกจาก Cloud (Egress Cost) และ Storage Cost สำหรับ Backup ที่เก็บระยะยาว
Shared Responsibility Model: ใครรับผิดชอบอะไรในเรื่อง Backup
Shared Responsibility Model เป็นแนวคิดพื้นฐานที่สำคัญมากสำหรับ Cloud Security รวมถึง Backup ทั้ง AWS, Azure และ GCP ใช้ Shared Responsibility Model ที่แบ่งความรับผิดชอบระหว่าง Cloud Provider กับ Customer
Cloud Provider รับผิดชอบ Security และ Availability ของ Cloud Infrastructure ได้แก่ Physical Security ของ Data Center Availability ของ Service (ตาม SLA) Hardware Maintenance และ Replacement Network Infrastructure Platform-level Redundancy (เช่น S3 มี 99.999999999% Durability) แต่ Cloud Provider ไม่รับผิดชอบ Backup ข้อมูลของ Customer ถ้า Customer ลบ Data ไปโดยไม่ได้ตั้งใจ หรือ Data ถูก Encrypt ด้วย Ransomware Cloud Provider ไม่มีหน้าที่กู้คืนให้
Customer รับผิดชอบ Data ของตัวเอง รวมถึง Backup Strategy ที่ต้องวางแผนและ Implement เอง Backup Schedule ที่ต้องกำหนดว่า Backup บ่อยแค่ไหน Backup Retention ที่ต้องกำหนดว่าเก็บ Backup นานแค่ไหน Backup Testing ที่ต้องทดสอบว่า Restore ได้จริง Disaster Recovery Plan ที่ต้องวางแผนว่าถ้า Region ล่มจะทำอย่างไร Data Protection Compliance ที่ต้อง Comply กับกฎหมายเช่น PDPA
หลายองค์กรเข้าใจผิดว่า Cloud Provider จะ Backup ข้อมูลให้อัตโนมัติ ซึ่งไม่จริง Cloud Provider มี Durability สูงมาก (เช่น S3 99.999999999%) หมายความว่า Data ไม่หายจาก Infrastructure Failure แต่ไม่ได้ป้องกัน Human Error (ลบผิด), Application Bug (เขียนทับ), Ransomware (Encrypt Data), Malicious Insider (พนักงานลบ Data) การมี Backup Strategy ที่ดีเป็นสิ่งจำเป็นแม้จะใช้ Cloud ที่มี Durability สูงแล้วก็ตาม
AWS Backup Options: ครบทุก Service ที่ต้องรู้
AWS มี Backup Options หลากหลายสำหรับ Service ต่างๆ ทั้ง Managed Backup Service และ Native Backup Feature ของแต่ละ Service
AWS Backup (Centralized Backup Service): AWS Backup เป็น Fully Managed Backup Service ที่ AWS สร้างขึ้นเพื่อเป็น Central Backup Management สำหรับ AWS Service หลายตัว รองรับ EC2 Instances, EBS Volumes, RDS Databases, DynamoDB Tables, EFS File Systems, FSx File Systems, Storage Gateway, DocumentDB, Neptune, S3, VMware on AWS ข้อดีของ AWS Backup คือ Centralized Management ที่ Manage Backup ของทุก Service จากที่เดียว Backup Policies ที่สร้าง Backup Plan ที่กำหนด Frequency, Retention, Lifecycle ได้ Cross-region Backup ที่ Copy Backup ไปยัง Region อื่นได้อัตโนมัติ Cross-account Backup ที่ Copy Backup ไปยัง AWS Account อื่นได้ (สำหรับ Protection จาก Account Compromise) Backup Vault Lock ที่ Lock Backup ไม่ให้ถูกลบได้ แม้แต่ Root Account (WORM – Write Once Read Many) Compliance Reporting ที่ Report ว่า Resource ไหน Compliant กับ Backup Policy หรือไม่ AWS Backup ราคาคิดตาม Storage ที่ใช้ และ Restore Request
EBS Snapshots: EBS (Elastic Block Store) Snapshot เป็นวิธีพื้นฐานที่สุดในการ Backup EC2 Instance EBS Snapshot เป็น Point-in-time Copy ของ EBS Volume ที่เก็บใน S3 (Managed โดย AWS ไม่เห็นใน S3 Console ของเรา) Snapshot แรกจะ Copy ข้อมูลทั้ง Volume (Full Snapshot) Snapshot ต่อๆ มาจะเป็น Incremental ที่ Copy เฉพาะ Block ที่เปลี่ยนแปลง ทำให้ประหยัด Storage และเวลา สามารถสร้าง Volume ใหม่จาก Snapshot ได้ทันที สามารถ Copy Snapshot ข้าม Region ได้สำหรับ DR EBS Snapshot สามารถ Automate ได้ด้วย Amazon Data Lifecycle Manager (DLM) ที่กำหนด Schedule และ Retention Policy หรือใช้ AWS Backup ข้อควรระวังคือ EBS Snapshot ไม่ใช่ Application-consistent Snapshot ถ้า Application มี Data ใน Memory ที่ยังไม่ Flush ลง Disk Snapshot อาจ Incomplete ควร Stop Application หรือ Freeze File System ก่อน Snapshot สำหรับ Critical Data
RDS Automated Backup: Amazon RDS (Relational Database Service) มี Automated Backup ในตัวที่เปิดใช้งานอัตโนมัติ RDS Automated Backup ทำ 2 อย่าง Automated Daily Snapshot ที่ Snapshot ทั้ง Database Instance ทุกวันใน Backup Window ที่กำหนด Transaction Log Backup ที่ Backup Transaction Log ทุก 5 นาที ทำให้สามารถ Point-in-Time Recovery (PITR) ได้ย้อนหลังไปจนถึง Retention Period ที่กำหนด (1-35 วัน) PITR สำคัญมากเพราะสามารถ Restore Database ไปยังจุดใดจุดหนึ่งที่ต้องการได้ เช่น Restore ไปยัง 5 นาทีก่อนที่จะมีคนลบ Table ผิด RDS Snapshot สามารถ Copy ข้าม Region ได้ สามารถ Share กับ AWS Account อื่นได้ RDS ยังมี Manual Snapshot ที่สร้างได้ตลอดเวลาและไม่มี Retention Limit (เก็บได้จนกว่าจะลบเอง)
S3 Versioning: S3 Versioning เป็น Feature ที่เก็บ Version ทุก Version ของ Object ใน S3 Bucket เมื่อเปิด Versioning ทุกครั้งที่ Upload Object ที่มีชื่อเดียวกัน S3 จะเก็บ Version เก่าไว้ ไม่ Overwrite ถ้าลบ Object S3 จะใส่ Delete Marker ไม่ได้ลบจริง สามารถ Recover Version เก่าได้ตลอดเวลา S3 Versioning ร่วมกับ S3 Object Lock (WORM) ป้องกัน Ransomware ได้ เพราะแม้ Ransomware จะ Encrypt File ใหม่ Version เก่าที่ไม่ถูก Encrypt ยังอยู่ ข้อควรระวังคือ S3 Versioning เพิ่ม Storage Cost เพราะเก็บทุก Version ควรใช้ S3 Lifecycle Policy เพื่อลบ Version เก่าที่ไม่ต้องการหรือย้ายไปยัง Storage Class ที่ถูกกว่า
DynamoDB Point-in-Time Recovery (PITR): DynamoDB PITR ให้ Continuous Backup ของ DynamoDB Table สามารถ Restore ไปยังจุดใดก็ได้ภายใน 35 วันที่ผ่านมา (Resolution 1 วินาที) PITR เปิดใช้งานง่ายมาก แค่ Enable ที่ Table Setting ราคาประมาณ $0.20 ต่อ GB ต่อเดือน DynamoDB ยังมี On-demand Backup ที่สร้าง Full Backup ได้ตลอดเวลา เก็บได้ไม่จำกัด ไม่มีผลต่อ Performance ของ Table และ AWS Backup ก็รองรับ DynamoDB ด้วย
Cross-Region Replication: สำหรับ Disaster Recovery ที่ต้องการ RPO (Recovery Point Objective) ต่ำ AWS มี Cross-Region Replication สำหรับหลาย Service S3 Cross-Region Replication (CRR) ที่ Replicate Object ไปยัง Bucket ใน Region อื่นแบบ Asynchronous RDS Cross-Region Read Replica ที่สร้าง Read Replica ใน Region อื่น ในกรณี DR สามารถ Promote Read Replica เป็น Primary ได้ DynamoDB Global Tables ที่ Replicate Table ไปยัง Region อื่นแบบ Active-Active Aurora Global Database ที่ Replicate Database ไปยัง Region อื่นด้วย Storage-level Replication ที่มี RPO ต่ำมาก (ไม่เกิน 1 วินาที)
Azure Backup Options: Backup บน Microsoft Azure
Microsoft Azure มี Backup Service ที่ครบถ้วนและ Integrate กับ Azure Service ต่างๆ ได้ดี
Azure Backup Service: Azure Backup เป็น Fully Managed Backup Service ของ Azure ที่รองรับหลาย Workload ได้แก่ Azure VM Backup ที่ Backup VM ทั้งเครื่อง (Full VM Backup) ด้วย VSS (Volume Shadow Copy Service) ที่เป็น Application-consistent Snapshot ทำได้ทั้ง Windows และ Linux VM SQL Server in Azure VM ที่ Backup SQL Server Database ที่รันบน Azure VM โดยไม่ต้องติดตั้ง Backup Agent เพิ่ม รองรับ Full, Differential และ Transaction Log Backup SAP HANA in Azure VM ที่ Backup SAP HANA Database ที่รันบน Azure VM Azure Files Backup ที่ Backup Azure File Share ด้วย Share Snapshot Azure Blobs Backup ที่ Backup Azure Blob Storage ด้วย Point-in-time Restore Azure Database for PostgreSQL/MySQL ที่ Backup Managed Database Azure Managed Disks ที่ Backup Azure Managed Disk ด้วย Incremental Snapshot
Azure Backup ใช้ Recovery Services Vault เป็นที่เก็บ Backup Data Recovery Services Vault เป็น Azure Resource ที่ Manage Backup Data, Backup Policies, Recovery Points Vault มี Storage Replication Option 3 แบบ LRS (Locally Redundant Storage) ที่ Replicate Data 3 copies ภายใน Data Center เดียว ราคาถูกที่สุด GRS (Geo-Redundant Storage) ที่ Replicate Data ไปยัง Secondary Region (Paired Region) ด้วย ราคาสูงกว่า LRS ประมาณ 2 เท่า แต่ปลอดภัยจาก Regional Disaster ZRS (Zone-Redundant Storage) ที่ Replicate Data ข้าม Availability Zone ภายใน Region เดียว
Azure Site Recovery (ASR): Azure Site Recovery ไม่ใช่ Backup Service โดยตรง แต่เป็น Disaster Recovery as a Service (DRaaS) ที่ Replicate VM จาก Primary Site ไปยัง Secondary Site (Azure Region อื่น หรือ On-Premise ไปยัง Azure) ASR ทำ Continuous Replication ของ VM Disk ไปยัง Target Region เมื่อเกิด Disaster สามารถ Failover ไปยัง Target Region ได้ภายในไม่กี่นาที RPO ประมาณ 30 วินาที ถึง 5 นาที RTO ประมาณ 2 ถึง 10 นาที ASR มี Recovery Plan ที่กำหนดลำดับการ Failover ของ VM หลายเครื่อง ทดสอบ DR ได้ด้วย Test Failover ที่ไม่กระทบ Production ASR เหมาะสำหรับ Critical Workload ที่ต้องการ RTO และ RPO ต่ำ
Geo-Redundant Storage (GRS): Azure Storage มี Redundancy Option หลายระดับ สำหรับ Backup ที่ต้องการ Protection จาก Regional Disaster ควรใช้ GRS ที่ Replicate Data ไปยัง Paired Region โดยอัตโนมัติ RA-GRS (Read-Access Geo-Redundant Storage) เพิ่มความสามารถในการ Read Data จาก Secondary Region ได้ด้วย GZRS (Geo-Zone Redundant Storage) Combine ZRS กับ GRS ให้ Protection ทั้ง Zone-level และ Region-level เหมาะสำหรับ Mission-Critical Data ที่ต้องการ Availability สูงสุด
Azure Backup มี Feature ที่น่าสนใจหลายอย่าง Soft Delete ที่เก็บ Deleted Backup Data ไว้อีก 14 วันหลังลบ ป้องกัน Accidental Deletion Multi-User Authorization ที่ต้องมี Approval จาก Resource Guard ก่อนจะลบ Backup ได้ ป้องกัน Malicious Deletion Immutable Vault ที่ทำให้ Backup Data ไม่สามารถลบหรือแก้ไขได้จนกว่าจะหมด Retention Period Private Endpoint ที่ Backup Traffic ไม่ต้องผ่าน Public Internet Encryption ที่ Backup Data Encrypted ทั้ง at rest (AES-256) และ in transit (TLS 1.2)
GCP Backup Options: Backup บน Google Cloud Platform
Google Cloud Platform มี Backup Options ที่ครอบคลุม Workload หลักบน GCP
Google Cloud Backup and DR: Google Cloud Backup and DR (เดิมชื่อ Actifio GO) เป็น Managed Backup and Disaster Recovery Service ของ GCP ที่เพิ่งเปิดตัวในปี 2022 และพัฒนาต่อเนื่องมาจนถึงปี 2026 รองรับ Compute Engine VM Backup ที่ Backup VM ทั้งเครื่อง Persistent Disk Backup ที่ Backup Disk แยกจาก VM Cloud SQL Backup ที่ Backup Cloud SQL Database GKE Backup ที่ Backup Google Kubernetes Engine Workload Cloud Backup and DR มี Centralized Management Console ที่ Manage Backup ทุก Workload จากที่เดียว Backup Plans ที่กำหนด Schedule, Retention, Storage Location ได้ Incremental Forever ที่ Backup เฉพาะ Block ที่เปลี่ยนแปลงหลังจาก Full Backup ครั้งแรก Mount and Access ที่ Mount Backup ได้ทันทีโดยไม่ต้อง Restore ทั้ง Disk สำหรับ Application Testing หรือ Data Verification
Persistent Disk Snapshots: Persistent Disk Snapshot เป็นวิธี Backup พื้นฐานสำหรับ Compute Engine VM Snapshot เป็น Point-in-time Copy ของ Persistent Disk ที่เก็บใน Cloud Storage (Managed โดย GCP) Snapshot แรกเป็น Full Copy ต่อๆ มาเป็น Incremental สามารถสร้าง Disk ใหม่จาก Snapshot ได้ สามารถสร้าง Snapshot ใน Region อื่นได้สำหรับ DR GCP มี Scheduled Snapshots ที่กำหนด Snapshot Schedule ได้ เช่น ทุกวัน ทุกชั่วโมง พร้อม Retention Policy ที่กำหนดว่าเก็บ Snapshot กี่วัน สำหรับ Application-consistent Snapshot GCP รองรับ VSS Snapshot สำหรับ Windows VM และ Pre/Post Snapshot Script สำหรับ Linux VM
Cloud SQL Backups: Cloud SQL (Managed MySQL, PostgreSQL, SQL Server) มี Automated Backup ในตัว Automated Daily Backup ที่ Backup ทุกวัน เก็บได้สูงสุด 365 วัน Point-in-Time Recovery (PITR) ที่ Recovery ไปยังจุดใดก็ได้ภายใน Retention Period ด้วย Binary Log (MySQL) หรือ WAL (PostgreSQL) On-demand Backup ที่สร้าง Backup ได้ตลอดเวลา เก็บได้ไม่จำกัด Cross-region Backup ที่เก็บ Backup ใน Region อื่นได้สำหรับ DR Cloud SQL ยังมี Cross-region Replica ที่ Replicate Database ไปยัง Region อื่นแบบ Asynchronous สำหรับ Read Scaling และ DR
GCP ยังมี Feature อื่นๆ ที่เกี่ยวกับ Data Protection เช่น Cloud Storage Versioning ที่เก็บทุก Version ของ Object ใน Cloud Storage Bucket คล้ายกับ S3 Versioning Cloud Storage Object Lock (Retention Policy) ที่ Lock Object ไม่ให้ถูกลบหรือแก้ไขได้จนกว่าจะหมด Retention Period BigQuery Snapshot ที่สร้าง Snapshot ของ BigQuery Dataset ได้ Filestore Backup ที่ Backup Managed NFS File Share ได้
Multi-Cloud Backup Strategy: Backup ข้ามหลาย Cloud Provider
หลายองค์กรใช้ Multi-Cloud Strategy ที่ใช้มากกว่าหนึ่ง Cloud Provider เช่น ใช้ AWS สำหรับ Production Workload หลัก ใช้ Azure สำหรับ Microsoft Workload (Office 365, Azure AD) ใช้ GCP สำหรับ Data Analytics และ Machine Learning การมี Workload กระจายอยู่หลาย Cloud ทำให้ Backup Strategy ซับซ้อนขึ้น
ปัญหาของ Multi-Cloud Backup คือ แต่ละ Cloud มี Native Backup Tool ที่แตกต่างกัน ไม่มี Central Management ข้าม Cloud Backup Policy อาจไม่สม่ำเสมอ (Inconsistent) ข้าม Cloud Reporting และ Compliance Monitoring ยากที่จะทำแบบ Cross-cloud Skill Requirement สูง ต้องมีคนที่รู้ Backup Tool ของทุก Cloud
แนวทางการจัดการ Multi-Cloud Backup มีหลายวิธี วิธีแรกคือใช้ Native Backup Tool ของแต่ละ Cloud แล้ว Manage แยกกัน วิธีนี้ง่ายที่สุดแต่ไม่มี Central Management เหมาะสำหรับองค์กรที่ใช้ Cloud Provider หนึ่งเป็นหลัก วิธีที่สองคือใช้ Third-party Backup Tool ที่รองรับ Multi-Cloud เช่น Veeam Backup for Cloud, Druva CloudRanger, Commvault Cloud Backup เครื่องมือเหล่านี้มี Central Console ที่ Manage Backup ของทุก Cloud จากที่เดียว Consistent Policy ข้าม Cloud Cross-cloud Reporting และ Compliance วิธีที่สามคือ Hybrid Approach ที่ใช้ Native Tool สำหรับ Backup หลัก แต่ใช้ Third-party Tool สำหรับ Cross-cloud Copy และ Long-term Retention
สำหรับ Multi-Cloud Backup ควรกำหนด Standard Backup Policy ที่ใช้ได้ทุก Cloud เช่น RPO ไม่เกิน 4 ชั่วโมงสำหรับ Production Workload Retention 30 วันสำหรับ Daily Backup Retention 1 ปีสำหรับ Monthly Backup Cross-region Copy สำหรับ Critical Workload Annual DR Test สำหรับ Critical Application
Backup สำหรับ Kubernetes บน Cloud: Velero และ Cloud Storage
Kubernetes (K8s) เป็น Container Orchestration Platform ที่นิยมมากบน Cloud ทั้ง AWS EKS, Azure AKS และ GCP GKE ล้วนเป็น Managed Kubernetes Service การ Backup Kubernetes มีความท้าทายเฉพาะตัวเพราะ Kubernetes ไม่ใช่แค่ VM ที่ Snapshot ได้ง่ายๆ Kubernetes ประกอบด้วยหลาย Component ที่ต้อง Backup ได้แก่ etcd ที่เป็น Cluster State Database ที่เก็บ Configuration ทั้งหมดของ Cluster Kubernetes Resources ที่เป็น YAML Definition ของ Deployment, Service, ConfigMap, Secret, Ingress ทุก Resource ที่อยู่ใน Cluster Persistent Volumes (PV) ที่เป็น Storage ที่ Mount กับ Pod เก็บ Data ของ Application เช่น Database Data, File Upload Application Configuration ที่เก็บใน ConfigMap และ Secret
Velero: Velero (เดิมชื่อ Heptio Ark) เป็น Open Source Tool ที่นิยมที่สุดสำหรับ Backup Kubernetes Velero สามารถ Backup Kubernetes Resources ที่ Export ทุก Resource Definition ออกมาเป็น YAML แล้วเก็บใน Cloud Storage (S3, Azure Blob, GCS) Backup Persistent Volumes ที่สร้าง Snapshot ของ PV ด้วย Cloud Provider API (EBS Snapshot, Azure Disk Snapshot, GCE Disk Snapshot) Schedule Backup ที่กำหนด Backup Schedule ได้ เช่น ทุกวัน ทุก 6 ชั่วโมง Restore ที่ Restore ทั้ง Cluster หรือเลือก Restore เฉพาะ Namespace หรือ Resource Type ที่ต้องการ Migrate ที่ Migrate Workload จาก Cluster หนึ่งไปอีก Cluster หนึ่งได้ แม้จะอยู่คนละ Cloud Provider
การติดตั้ง Velero บน Cloud แต่ละ Provider มีขั้นตอนคล้ายกัน สร้าง Cloud Storage Bucket สำหรับเก็บ Backup (S3 Bucket, Azure Blob Container, GCS Bucket) สร้าง IAM Role หรือ Service Account ที่มี Permission สำหรับ Snapshot Disk และ Write ไปยัง Storage Bucket ติดตั้ง Velero CLI บนเครื่อง Local ติดตั้ง Velero Server บน Kubernetes Cluster ด้วย velero install command กำหนด Backup Schedule ด้วย velero schedule create command
Best Practice สำหรับ Kubernetes Backup ได้แก่ Backup ทุก Namespace ไม่ใช่แค่ Application Namespace แต่รวม kube-system และ Namespace อื่นที่มี Custom Configuration Backup Secret และ ConfigMap ที่อาจมี Sensitive Data (แต่ Encrypt Backup ด้วย) ทดสอบ Restore เป็นประจำ โดย Restore ไปยัง Test Cluster แล้ว Verify ว่า Application ทำงานได้ถูกต้อง ใช้ Velero Hooks (Pre/Post Backup) สำหรับ Application ที่ต้อง Quiesce ก่อน Backup เช่น Database ที่ต้อง Freeze Write ก่อน Snapshot เก็บ Velero Backup ใน Storage ที่มี Versioning และ Object Lock เปิดอยู่
Backup สำหรับ SaaS: Microsoft 365 และ Google Workspace
SaaS (Software as a Service) เช่น Microsoft 365 (M365) และ Google Workspace เป็น Cloud Service ที่องค์กรส่วนใหญ่ใช้ หลายคนคิดว่า Microsoft หรือ Google จะ Backup ข้อมูลให้ แต่จริงๆ แล้ว SaaS Provider ไม่ได้ Backup ข้อมูลของ User ไว้ให้อย่างครบถ้วน
ทำไมต้อง Backup Microsoft 365: Microsoft 365 มี Recycle Bin และ Retention Policy ในตัว แต่มีข้อจำกัดหลายอย่าง Deleted Items ใน Exchange Online อยู่ใน Deleted Items Folder 30 วัน แล้วย้ายไป Recoverable Items Folder อีก 14 วัน (ขยายได้ถึง 30 วัน) หลังจากนั้นหายถาวร OneDrive Recycle Bin เก็บ File ที่ลบไว้ 93 วัน หลังจากนั้นหายถาวร SharePoint Recycle Bin เก็บไว้ 93 วัน Teams Chat ถูก Retain ตาม Retention Policy ที่กำหนด (Default ไม่ลบ แต่ไม่สามารถ Granular Restore ได้ง่าย) ปัญหาคือถ้าผู้ใช้ลบ Email หรือ File ไปแล้วเกิน Retention Period จะไม่สามารถ Recover ได้อีก ถ้า Admin ลบ User Account ข้อมูลทั้งหมดจะหายใน 30 วัน Ransomware ที่ Encrypt File บน OneDrive จะ Sync ขึ้น Cloud ทำให้ File บน Cloud ถูก Encrypt ด้วย (แม้จะมี Versioning แต่ Restore ทีละ File ทีละ Version ไม่สะดวก)
ทำไมต้อง Backup Google Workspace: Google Workspace มี Google Vault ที่เป็น eDiscovery และ Retention Tool แต่ Google Vault ไม่ใช่ Backup Tool เพราะ Google Vault เก็บ Data ตาม Retention Rule ที่กำหนด แต่ไม่สามารถ Restore Data กลับไปที่ User Account ได้โดยตรง Google Vault Export Data ออกมาเป็น File ต้อง Import กลับเอง Gmail Trash เก็บ Email ที่ลบไว้ 30 วัน Admin สามารถ Restore Email ที่ลบไปภายใน 25 วัน Google Drive Trash เก็บ File ที่ลบไว้ 30 วัน Admin สามารถ Restore File ที่ลบไปภายใน 25 วัน หลังจากนั้นหายถาวร (ยกเว้นมี Vault Retention Rule)
Third-party SaaS Backup Solutions: เพื่อ Backup M365 และ Google Workspace อย่างครบถ้วน ควรใช้ Third-party Backup Solution ที่ออกแบบมาสำหรับ SaaS Backup โดยเฉพาะ Veeam Backup for Microsoft 365 ที่ Backup Exchange Online, SharePoint Online, OneDrive, Teams เก็บ Backup ใน Cloud Storage (S3, Azure Blob) หรือ On-Premise Storage Granular Restore ที่ Restore ได้ตั้งแต่ทั้ง Mailbox จนถึง Email เดียว Druva inSync ที่ Backup M365 และ Google Workspace ได้ทั้งสองอย่าง เป็น SaaS-based Backup ไม่ต้องติดตั้ง Infrastructure เอง Automated Backup ทุก 4 ชั่วโมง (หรือ กำหนดเอง) Compliance Feature สำหรับ PDPA และ GDPR AvePoint Cloud Backup ที่ Backup M365 ได้ครบทุก Service (Exchange, SharePoint, OneDrive, Teams, Groups, Planner, Project) Backup ได้ถึง 4 ครั้งต่อวัน Unlimited Retention Backupify (Datto) ที่ Backup Google Workspace (Gmail, Drive, Calendar, Contacts, Sites) Automated Backup 3 ครั้งต่อวัน
Cost Optimization สำหรับ Cloud Backup
ค่าใช้จ่าย Cloud Backup อาจสูงกว่าที่คาดถ้าไม่ Manage อย่างเหมาะสม มี Strategy หลายอย่างที่ช่วย Optimize Cost
Storage Tiers: Cloud Provider ทุกเจ้ามี Storage Tier หลายระดับที่ราคาแตกต่างกันมาก AWS S3 มี S3 Standard ที่เหมาะสำหรับ Data ที่ Access บ่อย S3 Standard-IA (Infrequent Access) ที่ Storage ถูกกว่า Standard แต่มี Retrieval Fee เหมาะสำหรับ Backup ที่ไม่ค่อย Access S3 Glacier Instant Retrieval ที่ Storage ถูกมาก Retrieve ได้ทันที เหมาะสำหรับ Backup ที่เก็บระยะยาวแต่อาจต้อง Restore ทันที S3 Glacier Flexible Retrieval ที่ Storage ถูกมาก Retrieve ใช้เวลา 1-5 ชั่วโมง เหมาะสำหรับ Archive S3 Glacier Deep Archive ที่ Storage ถูกที่สุด (ประมาณ $1/TB/เดือน) Retrieve ใช้เวลา 12 ชั่วโมง เหมาะสำหรับ Long-term Archive ที่แทบไม่ต้อง Access Azure มี Hot, Cool, Cold และ Archive Tier GCP มี Standard, Nearline, Coldline และ Archive Class
Lifecycle Policies: Lifecycle Policy เป็น Rule ที่ย้าย Data จาก Storage Tier หนึ่งไปอีก Tier หนึ่งโดยอัตโนมัติตามอายุของ Data ตัวอย่าง Lifecycle Policy สำหรับ Backup Backup อายุ 0-30 วัน เก็บใน Standard Storage เพราะอาจต้อง Restore บ่อย Backup อายุ 30-90 วัน ย้ายไป Infrequent Access เพราะโอกาส Restore น้อยลง Backup อายุ 90-365 วัน ย้ายไป Glacier/Archive เพราะแทบไม่ต้อง Restore Backup อายุมากกว่า 365 วัน ลบทิ้ง (ถ้าไม่มี Compliance Requirement ที่ต้องเก็บนานกว่านี้) Lifecycle Policy ช่วยลดค่า Storage ได้มากโดยไม่ต้อง Manual Management
Deduplication และ Compression: Backup Tool หลายตัวรองรับ Deduplication ที่ตัด Data ที่ซ้ำกันออก และ Compression ที่บีบอัด Data ให้เล็กลง Deduplication สามารถลดขนาด Backup ได้ 50-90 เปอร์เซ็นต์ ขึ้นอยู่กับประเภทของ Data AWS Backup, Azure Backup และ GCP Backup ส่วนใหญ่ทำ Incremental Backup ที่ Backup เฉพาะ Data ที่เปลี่ยนแปลง ลดทั้ง Storage Cost และ Backup Time Third-party Tool เช่น Veeam, Commvault มี Advanced Deduplication ที่ลด Storage ได้มากกว่า Native Tool
Data Transfer Cost Optimization: Egress Cost (ค่า Download Data ออกจาก Cloud) เป็นค่าใช้จ่ายที่หลายคนมองข้าม AWS คิด Egress ประมาณ $0.09/GB Azure คิดประมาณ $0.087/GB GCP คิดประมาณ $0.12/GB ถ้า Restore Backup ขนาดใหญ่ Egress Cost อาจสูงมาก วิธี Optimize คือ เก็บ Backup ใน Cloud เดียวกันกับ Source ไม่ Cross-cloud Backup ถ้าไม่จำเป็น ใช้ Cross-region Copy ใน Cloud เดียวกันแทน Cross-cloud (Intra-cloud Transfer ราคาถูกกว่า Inter-cloud) ถ้าต้อง Download Backup ขนาดใหญ่ ใช้ AWS Snowball, Azure Data Box, GCP Transfer Appliance แทน Network Transfer
Compliance Requirements: PDPA และ Data Retention สำหรับ Cloud Backup
การ Backup ข้อมูลบน Cloud ต้องคำนึงถึง Compliance Requirements ที่เกี่ยวข้อง โดยเฉพาะ PDPA (Personal Data Protection Act) ของประเทศไทย ที่มีผลบังคับใช้ตั้งแต่ปี 2022
PDPA กำหนดให้องค์กรที่เก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลต้องมีมาตรการรักษาความปลอดภัยที่เหมาะสม Backup เป็นส่วนหนึ่งของมาตรการรักษาความปลอดภัย แต่ก็มีข้อกำหนดที่ต้องปฏิบัติตาม
Data Residency: PDPA ไม่ได้ห้ามการส่งข้อมูลส่วนบุคคลไปยังต่างประเทศ แต่กำหนดว่าประเทศปลายทางต้องมีมาตรฐานการคุ้มครองข้อมูลส่วนบุคคลที่เพียงพอ สำหรับ Cloud Backup ต้องพิจารณาว่า Backup Data ถูกเก็บอยู่ที่ Region ไหน ถ้าเป็น Cross-region Backup ข้อมูลอาจถูกส่งไปยัง Region ในต่างประเทศ AWS มี Region ใน Southeast Asia (Singapore) Azure มี Region ใน Southeast Asia (Singapore, Malaysia) GCP มี Region ใน Southeast Asia (Singapore, Indonesia) ถ้าต้อง Comply กับ Data Residency ควรเก็บ Backup ใน Region ที่อยู่ในประเทศหรือภูมิภาคที่อนุญาต
Data Retention Period: PDPA กำหนดให้เก็บข้อมูลส่วนบุคคลเท่าที่จำเป็น เมื่อหมดความจำเป็นต้องลบหรือทำให้ไม่สามารถระบุตัวตนได้ สำหรับ Backup ต้องมี Retention Policy ที่ชัดเจน กำหนดว่า Backup แต่ละประเภทเก็บนานแค่ไหน เมื่อหมด Retention Period ต้อง Delete Backup อัตโนมัติ ไม่เก็บ Backup ไว้ตลอดไปโดยไม่มีเหตุผล ใช้ Lifecycle Policy ลบ Backup เก่าอัตโนมัติ ต้องสามารถ Delete ข้อมูลของ Data Subject ออกจาก Backup ได้เมื่อได้รับ Request (Right to Erasure) ซึ่งเป็นเรื่องที่ท้าทายมากสำหรับ Backup เพราะ Backup มักเป็น Block-level ที่ไม่สามารถลบ Data ของคนใดคนหนึ่งออกได้ วิธีรับมือคือ กำหนด Retention Period ที่เหมาะสม เมื่อ Backup หมดอายุ Data ก็จะถูกลบไปโดยอัตโนมัติ
Encryption: PDPA กำหนดให้มีมาตรการรักษาความปลอดภัยที่เหมาะสม Encryption เป็นมาตรการพื้นฐานที่ต้องทำ Backup Data ต้อง Encrypt ทั้ง At Rest (เก็บอยู่ใน Storage) และ In Transit (ระหว่าง Transfer) AWS, Azure, GCP ทุกเจ้า Encrypt Storage by Default (Server-side Encryption) สามารถใช้ Customer Managed Key (CMK) สำหรับ Control ที่มากขึ้น ใช้ KMS (Key Management Service) ของ Cloud Provider สำหรับ Key Management
Testing Cloud Backup Recovery: ทดสอบการ Restore
Backup ที่ไม่เคยทดสอบ Restore ไม่ใช่ Backup ที่เชื่อถือได้ การทดสอบ Restore เป็นขั้นตอนที่สำคัญที่สุดแต่มักถูกละเลยมากที่สุด หลายองค์กร Backup ทุกวันเป็นเวลาหลายปี แต่ไม่เคยทดสอบ Restore เมื่อต้อง Restore จริงกลับพบว่า Backup Corrupt, Restore ไม่สำเร็จ, Application ไม่ทำงานหลัง Restore
ประเภทของ Restore Test: Restore Test มีหลายระดับ File-level Restore Test ที่ Restore File บางไฟล์จาก Backup แล้ว Verify ว่า File ถูกต้อง ไม่ Corrupt เป็น Test ที่ง่ายที่สุดและเร็วที่สุด ควรทำทุกสัปดาห์ Volume-level Restore Test ที่ Restore ทั้ง Volume จาก Snapshot แล้ว Mount กับ Test Server ตรวจสอบว่า File System ปกติ Data ครบถ้วน ควรทำทุกเดือน Application-level Restore Test ที่ Restore ทั้ง Application Stack (Server, Database, Configuration) แล้ว Verify ว่า Application ทำงานได้ถูกต้อง เป็น Test ที่สมบูรณ์ที่สุดแต่ใช้เวลาและ Resource มาก ควรทำทุกไตรมาส Full DR Test ที่จำลองสถานการณ์ Disaster จริง Failover ไปยัง DR Site ทดสอบ Application ทั้งหมด วัด RTO และ RPO จริง ควรทำอย่างน้อยปีละ 1-2 ครั้ง
การทำ Restore Test บน Cloud: Cloud ทำให้การ Restore Test ง่ายขึ้นมากเพราะสามารถ Provision Resource ชั่วคราวสำหรับ Test ได้ สร้าง VM จาก Snapshot หรือ Backup ใน Test Environment ทดสอบ Application แล้ว Terminate VM เมื่อเสร็จ จ่ายค่า Compute เฉพาะเวลาที่ Test เท่านั้น AWS มี CloudFormation ที่สร้าง Test Environment จาก Template ได้อัตโนมัติ Azure มี Azure Site Recovery Test Failover ที่ทดสอบ Failover ได้โดยไม่กระทบ Production GCP มี Deployment Manager ที่สร้าง Test Environment ได้
ทุก Restore Test ควรบันทึกผลลัพธ์เป็น Document ได้แก่ วันที่ทดสอบ ประเภทของ Test (File, Volume, Application, Full DR) Backup ที่ใช้ Test (Date, Type) ผลลัพธ์ (สำเร็จ/ไม่สำเร็จ) เวลาที่ใช้ในการ Restore (เทียบกับ RTO Target) ปัญหาที่พบ (ถ้ามี) Action Items สำหรับแก้ไขปัญหา ผู้รับผิดชอบ Document เหล่านี้เป็น Evidence สำหรับ Audit และ Compliance
Backup Automation ด้วย Terraform และ Ansible
Infrastructure as Code (IaC) เป็นแนวทางที่สำคัญสำหรับ Cloud Infrastructure Management รวมถึง Backup Automation การใช้ IaC สำหรับ Backup ทำให้ Backup Configuration เป็น Code ที่ Version Control ได้ Review ได้ Reproduce ได้ ไม่ต้อง Manual Configuration ที่อาจผิดพลาด
Terraform สำหรับ Backup Automation: Terraform เป็น IaC Tool ที่นิยมที่สุดสำหรับ Cloud Infrastructure ที่รองรับทั้ง AWS, Azure และ GCP Terraform สามารถ Manage Backup Resources ได้ทั้งหมด สำหรับ AWS Terraform สามารถสร้าง AWS Backup Vault, Backup Plan, Backup Selection ด้วย aws_backup_vault, aws_backup_plan, aws_backup_selection Resources สร้าง EBS Snapshot Policy ด้วย aws_dlm_lifecycle_policy Resource สร้าง RDS Automated Backup Configuration ด้วย aws_db_instance Resource (backup_retention_period, backup_window) สร้าง S3 Lifecycle Policy ด้วย aws_s3_bucket_lifecycle_configuration Resource สร้าง S3 Versioning ด้วย aws_s3_bucket_versioning Resource
สำหรับ Azure Terraform สามารถสร้าง Recovery Services Vault ด้วย azurerm_recovery_services_vault Resource สร้าง VM Backup Policy ด้วย azurerm_backup_policy_vm Resource สร้าง VM Backup Protection ด้วย azurerm_backup_protected_vm Resource สร้าง SQL Server Backup Policy ด้วย azurerm_backup_policy_vm_workload Resource สร้าง Blob Storage Backup ด้วย azurerm_data_protection_backup_policy_blob_storage Resource
สำหรับ GCP Terraform สามารถสร้าง Compute Disk Snapshot Schedule ด้วย google_compute_resource_policy Resource สร้าง Cloud SQL Backup Configuration ด้วย google_sql_database_instance Resource (backup_configuration block) สร้าง GKE Backup Plan ด้วย google_gke_backup_backup_plan Resource
Ansible สำหรับ Backup Automation: Ansible เป็น Configuration Management Tool ที่เหมาะสำหรับ Task Automation Ansible สามารถใช้สำหรับ Backup Task ที่ต้อง Execute Script หรือ Command บน Server Ansible Playbook สำหรับ Database Backup ที่ Execute mysqldump หรือ pg_dump แล้ว Upload ไปยัง Cloud Storage Ansible Playbook สำหรับ Application Backup ที่ Stop Application, Backup Data Directory, Start Application แล้ว Upload Backup ไปยัง S3/Azure Blob/GCS Ansible Playbook สำหรับ Backup Verification ที่ Download Backup, Restore ไปยัง Test Environment, Run Verification Script, Report Result Ansible สามารถใช้ร่วมกับ Cloud Module ได้ เช่น amazon.aws Collection สำหรับ AWS, azure.azcollection สำหรับ Azure, google.cloud Collection สำหรับ GCP
Best Practice สำหรับ Backup Automation ด้วย IaC ได้แก่ เก็บ Backup Configuration ใน Git Repository ให้ Version Control ใช้ Terraform Module สำหรับ Backup Pattern ที่ใช้ซ้ำหลาย Environment ใช้ CI/CD Pipeline (GitHub Actions, GitLab CI, Azure DevOps) สำหรับ Deploy Backup Configuration ใช้ Terraform State Backend ที่ปลอดภัย (S3 + DynamoDB Lock, Azure Storage + State Locking) ใช้ Variable สำหรับ Configuration ที่แตกต่างกันแต่ละ Environment (Dev, Staging, Production) Review Backup IaC Code เหมือน Application Code ก่อน Merge
Cloud-to-Cloud Backup Tools: Veeam, Druva และ Commvault
สำหรับองค์กรที่ต้องการ Enterprise-grade Backup Solution ที่ครอบคลุมทั้ง Cloud และ On-Premise มี Third-party Backup Tool หลายตัวที่เป็นผู้นำในตลาด
Veeam Backup and Replication: Veeam เป็น Backup Solution ที่ได้รับความนิยมสูงสุดในตลาด Enterprise Backup โดยเฉพาะสำหรับ Virtual Machine และ Cloud Workload Veeam รองรับ AWS (EC2, RDS, EFS, VPC Configuration) Azure (VM, SQL, Files, Blob) GCP (Compute Engine VM) On-Premise (VMware vSphere, Microsoft Hyper-V, Physical Server) Kubernetes (Kasten K10 ที่ Veeam ซื้อมา) Microsoft 365 (Exchange Online, SharePoint Online, OneDrive, Teams) Veeam มี Feature เด่นหลายอย่าง Instant Recovery ที่ Boot VM จาก Backup ได้ทันทีโดยไม่ต้อง Restore ลดเวลา Recovery เหลือไม่กี่นาที SureBackup ที่ทดสอบ Backup อัตโนมัติโดย Boot VM จาก Backup ใน Sandbox แล้ว Verify ว่า Application ทำงานได้ Veeam ONE ที่ Monitoring และ Reporting สำหรับ Backup Environment CDP (Continuous Data Protection) สำหรับ Critical VM ที่ต้องการ RPO เกือบ 0 Object Storage Support ที่เก็บ Backup ใน S3-Compatible Object Storage ได้
Druva: Druva เป็น Cloud-native Backup SaaS ที่ไม่ต้องติดตั้ง Infrastructure เลย ทุกอย่างเป็น SaaS Druva รองรับ AWS (EC2, RDS, DynamoDB, Redshift, EBS, Aurora, DocumentDB, Neptune) Azure (VM, SQL, Blob) Microsoft 365 (Exchange, OneDrive, SharePoint, Teams) Google Workspace (Gmail, Drive) Endpoint (Laptop, Desktop) ข้อดีของ Druva คือ Zero Infrastructure ที่ไม่ต้อง Deploy Backup Server เอง ทุกอย่างเป็น SaaS ลด Complexity และ Management Overhead Global Deduplication ที่ Deduplicate ข้าม Source ทุกตัว ลด Storage Cost ได้มาก Ransomware Recovery ที่ Detect Ransomware Activity แล้ว Alert ก่อนที่ Backup จะถูก Corrupt Compliance ที่มี Built-in Compliance Framework สำหรับ GDPR, HIPAA, SOC 2
Commvault: Commvault เป็น Enterprise Backup Solution ที่มีมายาวนานและมี Feature ครบถ้วนที่สุดในตลาด Commvault รองรับ Workload หลากหลายที่สุด ทั้ง Cloud, On-Premise, SaaS, Container, Edge Commvault มี Feature เด่นหลายอย่าง Command Center ที่ Web-based Management Console ที่ Manage Backup ทุก Workload จากที่เดียว Metallic (Commvault SaaS) ที่เป็น SaaS Version สำหรับองค์กรที่ไม่ต้องการ Manage Backup Infrastructure เอง IntelliSnap ที่ Integrate กับ Storage Snapshot (NetApp, Pure Storage, Dell EMC) สำหรับ Application-consistent Backup ที่เร็วมาก Hedvig (Distributed Storage) ที่เป็น Software-defined Secondary Storage สำหรับ Backup Air Gap Protection ที่ Isolate Backup Copy จาก Production Network ป้องกัน Ransomware
การเลือก Backup Tool ขึ้นอยู่กับหลายปัจจัย ถ้าใช้ VMware เป็นหลักและเริ่ม Move ไป Cloud Veeam เป็นตัวเลือกที่ดีที่สุดเพราะ Integration ดีและ Feature ครบ ถ้าต้องการ Zero Infrastructure และใช้ Cloud/SaaS เป็นหลัก Druva เป็นตัวเลือกที่ดีเพราะไม่ต้อง Manage อะไรเลย ถ้ามี Workload หลากหลายมากทั้ง Cloud, On-Premise, Mainframe, SAP Commvault มี Coverage กว้างที่สุด ถ้ามี Budget จำกัดและใช้ Cloud Provider เดียว Native Backup Tool (AWS Backup, Azure Backup, GCP Backup) อาจเพียงพอ
Cloud Backup เป็นหัวข้อที่กว้างและซับซ้อน แต่เป็นสิ่งที่ IT Admin ทุกคนต้องเข้าใจในยุคที่ Workload ส่วนใหญ่อยู่บน Cloud สรุปสิ่งสำคัญที่ต้องจำ อย่าเข้าใจผิดว่า Cloud Provider จะ Backup ให้ Shared Responsibility Model บอกชัดเจนว่า Backup เป็นหน้าที่ของ Customer ใช้ Native Backup Tool สำหรับ Backup พื้นฐาน และ Third-party Tool สำหรับ Advanced Requirements Optimize Cost ด้วย Storage Tiers, Lifecycle Policies และ Deduplication คำนึงถึง Compliance เช่น PDPA สำหรับ Data Retention และ Data Residency ทดสอบ Restore เป็นประจำ Backup ที่ไม่เคย Test Restore ไม่ใช่ Backup ที่เชื่อถือได้ ใช้ IaC (Terraform, Ansible) สำหรับ Backup Automation เพื่อ Consistency และ Reproducibility การลงทุนเวลาและ Resource ในการวาง Cloud Backup Strategy ที่ดีจะคุ้มค่ามากเมื่อเกิดเหตุการณ์ที่ต้อง Restore ข้อมูลจริง
