时间戳

首页 > 解决方案 > 调整启动磁盘 VM（Google Cloud）的大小后网站完全关闭

google-cloud-platform - 调整启动磁盘 VM（Google Cloud）的大小后网站完全关闭

问题描述

我不得不将我的 Debian Linux VM 的启动磁盘从 10GB 调整到 30GB，因为它已满。在这样做并停止/启动我的实例之后，它变得无用了。我无法进入 SSH，也无法访问我的应用程序。从 1 个月前开始的最后一次备份，如果我不让这个工作，我们将失去很多工作。

我已经阅读了互联网上关于调整磁盘大小和重新分区表的几乎所有内容，但似乎没有任何效果。

运行时df -h我看到：

Filesystem      Size  Used Avail Use% Mounted on
overlay          36G   30G  5.8G  84% /
tmpfs            64M     0   64M   0% /dev
tmpfs           848M     0  848M   0% /sys/fs/cgroup
/dev/sda1        36G   30G  5.8G  84% /root
/dev/sdb1       4.8G   11M  4.6G   1% /home
overlayfs       1.0M  128K  896K  13% /etc/ssh/keys
tmpfs           848M  744K  847M   1% /run/metrics
shm              64M     0   64M   0% /dev/shm
overlayfs       1.0M  128K  896K  13% /etc/ssh/ssh_host_dsa_key
tmpfs           848M     0  848M   0% /run/google/devshell

运行时sudo lsblk我看到：

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   40G  0 disk
├─sda1    8:1      35.9G  0 part /var/lib/docker
├─sda2    8:2    0   16M  1 part
├─sda3    8:3    0    2G  1 part
├─sda4    8:4    0   16M  0 part
├─sda5    8:5    0    2G  0 part
├─sda6    8:6       512B  0 part
├─sda7    8:7    0  512B  0 part
├─sda8    8:8        16M  0 part
├─sda9    8:9    0  512B  0 part
├─sda10   8:10   0  512B  0 part
├─sda11   8:11        8M  0 part
└─sda12   8:12   0   32M  0 part
sdb       8:16   0    5G  0 disk
└─sdb1    8:17   0    5G  0 part /home
zram0   253:0    0  768M  0 disk [SWAP]

在增加磁盘大小之前，我确实尝试添加第二个磁盘，我什至按照谷歌云文档格式化并安装它，然后再次卸载它。（所以我编辑了 fstab 和 fstab.backup 等。）

谷歌云文档上的调整磁盘大小/重新分区表对我没有任何作用。. growpart,fdisk和resize2fs许多其他 StackOverflow 帖子都没有。

尝试通过 SSH 访问时，我收到“无法在端口 22 上连接”错误，如google cloud docs中所述

使用新磁盘创建新的 Debian Linux 实例时，它可以正常工作。

任何可以在不丢失任何数据的情况下为我启动并运行它的人都会获得 100+ 和很多爱......

标签： google-cloud-platformcloudgoogle-cloud-storagegoogle-compute-engine

解决方案

我试图复制案例场景，但它没有给我带来任何 VM 实例问题。

我创建了一个包含 10 GB 数据的 VM 实例，然后将其停止，将磁盘大小增加到 30 GB 并再次启动该实例。您提到您无法通过 ssh 访问实例或访问您的应用程序。在我的测试之后，我可以通过 ssh 进入实例。因此，您所遵循的过程肯定存在损坏 VM 实例或引导磁盘的问题。

但是，有一种解决方法可以从您无法通过 SSH 访问的实例中恢复文件。我已经对其进行了测试，并且对我有用：

  1. 转到 Compute Engine 页面，然后转到Images
  2. 点击“[+] 创建图像”
  3. 为该图像命名并在Source选择下Disk
  4. 在Source disk选择您已调整大小的 VM 实例的磁盘下。
  5. 点击Save，如果磁盘的虚拟机正在运行，会报错。要么先停止 VM 实例，然后再次执行相同的步骤，要么只选中该框Keep instance running (not recommended)。（我建议先停止它，正如错误所暗示的那样）。
  6. 保存新创建的图像后。选择它并单击+ CREATE INSTANCE
  7. 为该实例命名并保留所有设置。
  8. 在引导磁盘下，您确保看到您之前在增加磁盘大小时设置的 30 GB 大小，并且名称应该是您创建的映像的名称。
  9. 单击创建并尝试通过 SSH 连接到新创建的实例。
  10. 如果在调整磁盘大小时保留了所有文件，则应该能够访问在 VM 损坏之前拥有的最新文件。

更新第二个解决方法 - 将引导磁盘作为辅助磁盘附加到另一个 VM 实例

为了将磁盘从损坏的 VM 实例附加到新的 GCE 实例，您需要执行以下步骤：

  1. 转到Compute Engine > Snapshots并单击+ CREATE SNAPSHOT。
  2. 在 下Source disk，选择损坏的 VM 的磁盘。创建快照。
  3. 转到Compute Engine > Disks并单击+ CREATE DISK。
  4. 在Source type转到Snapshot和下Source snapshot选择您从步骤 2 中创建的新快照。创建磁盘。
  5. 转到Compute Engine > VM instances并单击+ CREATE INSTANCE。
  6. 将所有设置保留为默认设置。在Firewall启用Allo HTTP traffic和Allow HTTPS traffic。
  7. 点击Management, security, disks, networking, sole tenancy
  8. 单击Disks选项卡。
  9. 单击+ Attach existing disk并Disk选择新创建的磁盘。创建新的 VM 实例。
  10. SSH 进入虚拟机并运行$ sudo lsblk
  11. 检查新附加磁盘的设备名称及其主分区（可能是 /dev/sdb1）
  12. 创建一个目录以将磁盘挂载到：$ sudo mkdir -p /mnt/disks/mount
  13. 将磁盘挂载到新创建的目录$ sudo mount -o discard,defaults /dev/sdb1 /mnt/disks/mount
  14. 然后您应该能够从磁盘加载所有文件。我自己测试过，我可以用这种方法从旧磁盘中再次恢复文件。

推荐阅读