Compute Engine：私网访问与磁盘恢复

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

创建与维护 VM；Console：Compute Engine → VM instances。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
ZONE='REPLACE_ZONE'
VM='REPLACE_VM'

gcloud compute instances describe "$VM" --project="$PROJECT_ID" --zone="$ZONE"
gcloud compute ssh "$VM" --project="$PROJECT_ID" --zone="$ZONE" --tunnel-through-iap

容易踩的坑#

IAP tunnel 权限、OS Login、VM SA actAs 和 TCP 22 firewall 是不同检查。
停止 VM 不会停止所有磁盘/地址费用；看到恢复盘不等于数据已验证。

IAP 权限与失败定位 · MIG

配置说明与完整示例（按需展开）

前置：VPC 实验。本篇负责 VM、磁盘和快照生命周期；登录机制、IAP/OS Login 权限与排障统一见 IAP：VM SSH 与 TCP forwarding。创建资源的操作者还需 VM 管理权限，以及将 Service Account 附加到 VM 的 actAs 权限。

创建无公网 IP 的 VM#

source lab.env
export VM_SA="lab-vm@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts create lab-vm
# 不给 VM SA 分配业务权限。
gcloud compute instances create lab-vm \
  --zone="$ZONE" \
  --machine-type=e2-micro \
  --subnet=lab-subnet \
  --no-address \
  --tags=iap-ssh \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --service-account="$VM_SA" \
  --scopes=cloud-platform \
  --metadata=enable-oslogin=TRUE

# 创建完成后，先按 IAP 子页核对登录前提；这里执行远程出站验收。
gcloud compute ssh lab-vm --zone="$ZONE" --tunnel-through-iap --command='hostname; curl -I --max-time 15 https://example.com'

cloud-platform scope 不等于获得所有云权限，实际还受 SA 的 IAM 限制。--no-address 使实例没有外部 IP。VM 参数

快照与恢复磁盘#

先在本例 VM 的启动盘写入标记并同步；后面要从恢复盘读回同一内容：

gcloud compute ssh lab-vm --zone="$ZONE" --tunnel-through-iap \
  --command='printf "snapshot-lab-v1\n" | sudo tee /var/tmp/snapshot-marker; sync'

在本机创建快照、恢复新磁盘并以只读方式附加：

gcloud compute disks snapshot lab-vm --zone="$ZONE" --snapshot-names=lab-vm-snapshot
gcloud compute disks create lab-restored --zone="$ZONE" --source-snapshot=lab-vm-snapshot
gcloud compute instances attach-disk lab-vm --zone="$ZONE" \
  --disk=lab-restored --device-name=lab-restored --mode=ro
gcloud compute ssh lab-vm --zone="$ZONE" --tunnel-through-iap --command='lsblk'

lsblk 只证明块设备出现，尚未证明数据可读。通过 IAP 进入 VM：

gcloud compute ssh lab-vm --zone="$ZONE" --tunnel-through-iap

恢复盘只读挂载，不要格式化，也不要误选当前启动盘。 在 VM shell 用 lsblk 和 by-id 路径确认 lab-restored 的 root filesystem 分区；本例 ext4 使用只读且不重放 journal 的挂载方式：

ls -l /dev/disk/by-id/google-lab-restored*
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTS
# 替换为已确认属于 lab-restored 的 ext4 root 分区完整路径。
export RESTORED_PART='REPLACE_RESTORED_ROOT_PARTITION'
sudo mkdir -p /mnt/lab-restored
sudo mount -t ext4 -o ro,noload "$RESTORED_PART" /mnt/lab-restored
sudo cat /mnt/lab-restored/var/tmp/snapshot-marker
sudo cmp /var/tmp/snapshot-marker /mnt/lab-restored/var/tmp/snapshot-marker
sudo umount /mnt/lab-restored
exit

验收：恢复盘输出 snapshot-lab-v1，cmp 返回 0；再回到本机清理。若文件系统不是 ext4，按对应挂载规则处理，不照抄选项。在线快照仍不保证数据库应用一致性，数据库使用自身备份机制。快照恢复

清理#

gcloud compute instances detach-disk lab-vm --zone="$ZONE" --disk=lab-restored
gcloud compute instances delete lab-vm --zone="$ZONE"
gcloud compute disks delete lab-restored --zone="$ZONE"
gcloud compute snapshots delete lab-vm-snapshot
gcloud iam service-accounts delete "$VM_SA"

停止 VM 仍可能有磁盘等费用。磁盘、快照、地址分别核对。

需要按模板维护一组 VM、扩缩容或滚动发布时，继续 Instance Template 与 MIG。先保留网络、NAT 与 IAP 前置资源，再完成该篇实验。