Backup, Snapshot & Recovery trong Filestore

Tại sao quan trọng trong production

Filestore là shared filesystem — khi có sự cố (xóa nhầm dữ liệu, corruption, zone outage), tất cả các service đang mount đều bị ảnh hưởng đồng thời. Recovery strategy không tốt đồng nghĩa với downtime cho toàn bộ workload phụ thuộc vào instance đó.

Điều khiến Filestore data protection phức tạp hơn block storage là: Filestore snapshot và backup hoạt động theo cơ chế hoàn toàn khác nhau, với trade-off khác nhau. Hiểu sai sự khác biệt dẫn đến chọn sai phương án và không thể recover khi cần.

Internal model — Backup là gì

Cơ chế backup

Filestore backup là differential copy của file share data. Cụ thể:

• Backup đầu tiên: copy toàn bộ data của file share
• Backup tiếp theo: copy chỉ phần data thay đổi so với backup trước (incremental/differential)

Backup được lưu trữ bên ngoài instance — đây là điểm khác biệt cốt lõi với snapshot. Backup là regional resource được Google lưu trong Cloud Storage infrastructure (bạn không quản lý bucket này trực tiếp), có thể ở khác region so với instance gốc.

Điều này nghĩa là:

• Instance bị xóa → backup vẫn tồn tại
• Zone hay region incident ảnh hưởng instance → backup ở region khác vẫn an toàn
• Phí backup tiếp tục tính dù instance đã bị xóa (cho đến khi bạn xóa backup)

Những gì được preserve và không được preserve

Được preserve trong backup:

• Tất cả file data và metadata
• Cấu hình của instance gốc: tier, capacity, file share name
• IP-based access control rules

KHÔNG được preserve:

• File locks (NFS file locks không persistent)
• Instance description, location, network configuration
• IP address của instance gốc
• Snapshots (backup không include snapshots)
• Label và tag tùy chỉnh

Implication của "không preserve location/network": Khi restore từ backup, bạn tạo một instance mới. Instance mới này sẽ có IP khác — tất cả client đang dùng IP cũ sẽ cần update mount point.

Backup types

Standard Backup:

• Được quản lý trực tiếp qua Filestore API hoặc Console
• Retention: vô hạn (cho đến khi bạn xóa)
• Không có built-in scheduling (phải tự schedule bằng Cloud Scheduler + Cloud Functions hoặc Terraform)
• Support tất cả tiers

Enhanced Backup (qua Backup and DR Service):

• Managed scheduling với backup policies
• Immutable vault protection (backup không thể bị xóa trong retention period, kể cả admin)
• Granular recovery management qua Backup and DR console
• Phù hợp cho compliance requirements yêu cầu immutable backup

Internal model — Snapshot là gì

Cơ chế snapshot

Snapshot trong Filestore hoạt động theo cơ chế copy-on-write (CoW) at the instance level. Khi tạo snapshot:

1. Filestore ghi nhận "checkpoint" của filesystem state tại thời điểm đó
2. Không copy data ngay — snapshot ban đầu chiếm gần 0 byte thêm
3. Khi có ghi mới vào live filesystem, block cũ được preserved trong snapshot
4. Dữ liệu chỉ thực sự duplicate khi live filesystem và snapshot diverge

Timeline:
t=0: Snapshot S1 created
     [Live FS]  [S1]
     Block A    Block A (shared reference)
     Block B    Block B (shared reference)

t=1: Live FS modifies Block A
     [Live FS]  [S1]
     Block A'   Block A (preserved original)
     Block B    Block B (still shared)

t=2: Snapshot S2 created
     [Live FS]  [S1]       [S2]
     Block A'   Block A    Block A' (shared with live)
     Block B    Block B    Block B (shared with all)

Snapshot không tốn storage ban đầu nhưng tốn dần theo thời gian khi live filesystem thay đổi nhiều hơn so với snapshot point. Tất cả snapshots share data chung nhau — chỉ preserve differences.

Snapshots nằm ở đâu

Snapshot là child resource của instance — khác hoàn toàn với backup. Điều này có nghĩa:

• Snapshot nằm trong storage của instance (chiếm capacity)
• Không tiêu thụ capacity riêng biệt ngay khi tạo, nhưng tăng dần
• Instance bị xóa → snapshot bị xóa
• Zone incident ảnh hưởng instance → snapshot cũng không accessible
• Maximum 240 snapshots per instance

Snapshot được access qua hidden .snapshot directory trong mỗi directory của share:

# User có thể tự restore file
ls /mnt/filestore/.snapshot/
# 2024-01-15-0300  2024-01-16-0300  2024-01-17-0300

# Restore file từ snapshot
cp /mnt/filestore/.snapshot/2024-01-15-0300/important_file.txt \
   /mnt/filestore/important_file.txt

Đây là điểm mạnh của snapshot: self-service file recovery mà không cần admin intervention.

Tiers support snapshot

Tier	Snapshot support
Basic HDD	Không
Basic SSD	Không
Zonal	Có
Regional	Có
Enterprise/Multishares	Không (Enterprise có, nhưng không support khi dùng Multishares)

Basic tiers không có snapshot là lý do chính để migrate lên Zonal/Regional tier cho production workloads.

So sánh Snapshot vs Backup

Khía cạnh	Snapshot	Backup
Vị trí lưu trữ	Trong instance (cùng zone)	Regional/Cross-region (ngoài instance)
Instance bị xóa	Snapshot bị xóa theo	Backup vẫn tồn tại
Zone incident	Không accessible	An toàn nếu backup ở region khác
Tốc độ tạo	Gần instant (< 2 phút)	Chậm hơn (phụ thuộc data size)
Granular restore	Có (per-file qua .snapshot)	Không (restore toàn bộ instance)
Instance mới khi restore	Không (revert in-place)	Có (tạo instance mới)
Thay đổi IP khi restore	Không	Có (instance mới có IP khác)
Max số lượng	240/instance	Không giới hạn (bởi Filestore, GCP quotas áp dụng)
Storage cost	Tính vào instance storage	Tính riêng theo backup size

Mental model đúng:

• Snapshot: bảo vệ chống lại sai lầm của user (xóa nhầm file, ghi đè nhầm). Recovery nhanh, không ảnh hưởng IP. Không bảo vệ chống lại zone failure.
• Backup: bảo vệ chống lại zone failure, instance deletion, và là cross-region DR strategy. Recovery chậm hơn, cần update mount points.

Trong production, dùng cả hai: snapshot cho operational recovery, backup cho disaster recovery.

Recovery process

Recovery từ Snapshot — Revert instance

Revert instance về một snapshot là irreversible operation:

# Revert instance về snapshot
gcloud filestore instances revert INSTANCE_NAME \
  --zone=ZONE \
  --source-snapshot=SNAPSHOT_NAME

Điều gì xảy ra khi revert:

1. Toàn bộ live filesystem bị replace bằng state tại thời điểm snapshot
2. Tất cả thay đổi sau thời điểm snapshot bị mất vĩnh viễn
3. Tất cả snapshots sau snapshot đang revert về bị xóa
4. NFS file system ID thay đổi → clients giữ mount sẽ gặp stale NFS handle errors
5. Revert mất khoảng 2 phút, sau đó cleanup trong background có thể mất 6–10 ngày

Critical: Vì NFS file system ID thay đổi, tất cả NFS clients phải unmount và remount sau revert. Kubernetes pods dùng Filestore sẽ cần restart.

Recovery per-file từ Snapshot

Cách phổ biến hơn và ít rủi ro hơn là restore individual files từ .snapshot directory:

# List available snapshots
ls /mnt/filestore/.snapshot/

# Xem file tại thời điểm snapshot
ls -la /mnt/filestore/.snapshot/snap-2024-01-15/

# Restore file cụ thể
cp /mnt/filestore/.snapshot/snap-2024-01-15/config.yaml \
   /mnt/filestore/config.yaml

# Restore toàn bộ thư mục
cp -r /mnt/filestore/.snapshot/snap-2024-01-15/data/ \
      /mnt/filestore/data_restored/

Cách này không cần admin access, user có quyền read trên mount có thể tự recover file.

Recovery từ Backup — Restore instance

Restore từ backup luôn tạo instance mới:

# Restore to new instance từ backup
gcloud filestore instances create RESTORED_INSTANCE \
  --zone=TARGET_ZONE \
  --tier=TIER \
  --file-share=name="vol1",capacity=1TiB \
  --network=name="default" \
  --source-backup=projects/PROJECT/locations/REGION/backups/BACKUP_NAME

Sau khi instance mới được tạo (5–10 phút), bạn sẽ có IP mới. Tất cả clients cần update mount point sang IP mới.

Basic HDD/SSD special case: Các tier này hỗ trợ restore vào instance cũng instance (overwrite in-place). Tuy nhiên cách này:

• Dừng service trong quá trình restore
• Tất cả data sau thời điểm backup bị mất
• Không khuyến khích cho production

Recovery từ cross-region backup:

Nếu region chính bị incident và bạn có backup ở region khác:

# Tạo instance mới ở region backup
gcloud filestore instances create DR_INSTANCE \
  --zone=us-east1-b \                         # zone ở DR region
  --tier=enterprise \
  --file-share=name="vol1",capacity=2TiB \
  --network=name="projects/PROJECT/global/networks/VPC" \
  --source-backup=projects/PROJECT/locations/us-central1/backups/BACKUP_NAME

Đây là DR playbook thực tế: backup cross-region → khi cần, restore vào region mới → update DNS hoặc IP trong config → redirect traffic.

Failure modes khi không có backup/snapshot

Scenario 1: Xóa nhầm file

• Nếu có snapshot trong 24h gần nhất: recover từ .snapshot directory, mất tối đa 24h data
• Nếu không có snapshot: data mất vĩnh viễn

Scenario 2: Instance bị xóa nhầm

• Nếu có backup: restore lên instance mới (mất data từ backup time đến lúc xóa)
• Snapshot của instance cũng bị xóa theo
• Nếu không có backup: toàn bộ data mất

Scenario 3: Corruption do application bug

Corruption thường propagate dần dần — snapshot tại thời điểm corruption cũng bị corrupt. Cần có snapshot có age đủ xa để rollback về state trước corruption, và retention policy đủ dài để có snapshot cũ.

Recommendation: Giữ ít nhất 7 ngày snapshots daily + 30 ngày monthly backups cho production data.

GCP-native implementation

Snapshot scheduling

Filestore không có built-in snapshot scheduler. Dùng Cloud Scheduler + Cloud Functions:

# Cloud Function được trigger bởi Cloud Scheduler
import google.cloud.filestore_v1 as filestore

def create_snapshot(request):
    client = filestore.CloudFilestoreManagerClient()
    
    snapshot = filestore.Snapshot(
        description="Daily automated snapshot"
    )
    
    parent = "projects/PROJECT/locations/ZONE/instances/INSTANCE"
    operation = client.create_snapshot(
        parent=parent,
        snapshot=snapshot,
        snapshot_id=f"daily-{datetime.now().strftime('%Y%m%d')}"
    )
    return "Snapshot created"

Backup scheduling với Cloud Scheduler

# Tạo backup hàng ngày lúc 2AM
gcloud scheduler jobs create http daily-filestore-backup \
  --schedule="0 2 * * *" \
  --uri="https://file.googleapis.com/v1/projects/PROJECT/locations/REGION/backups" \
  --message-body='{
    "sourceInstance": "projects/PROJECT/locations/ZONE/instances/INSTANCE",
    "sourceFileShare": "vol1",
    "description": "Daily automated backup"
  }' \
  --oauth-service-account-email=backup-sa@PROJECT.iam.gserviceaccount.com

Giữ N backups gần nhất

from google.cloud import filestore_v1

def cleanup_old_backups(project, region, keep_n=7):
    client = filestore_v1.CloudFilestoreManagerClient()
    parent = f"projects/{project}/locations/{region}"
    
    backups = list(client.list_backups(parent=parent))
    backups.sort(key=lambda b: b.create_time, reverse=True)
    
    for backup in backups[keep_n:]:
        client.delete_backup(name=backup.name)

References

• Filestore Backups
• Filestore Snapshots
• Compare snapshots and backups
• Backup and DR Service for Filestore