调整启动磁盘VM(Google Cloud)大小后,网站完全关闭

时间:2019-03-19 22:55:39

标签: google-cloud-platform cloud google-cloud-storage google-compute-engine

我不得不将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]

在增加磁盘大小之前,我确实尝试添加第二个磁盘,甚至按照Google Cloud docs对其进行了格式化和安装,然后再次将其卸载。 (所以我编辑了fstab和fstab.backup等。)

谷歌云文档上有关调整磁盘/分区表大小的任何事情对我来说都没有用。growpartfdiskresize2fs和许多其他StackOverflow帖子都没有。

当尝试通过SSH访问时,出现google cloud docs

中所述的“无法在端口22上连接”错误。

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

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

1 个答案:

答案 0 :(得分:1)

我试图复制这种情况,但是并没有给我带来任何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正在运行,则会出现错误。请先停止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 trafficAllow 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. 然后,您应该能够从磁盘加载所有文件。我已经对其进行了测试,可以使用这种方法再次从旧磁盘中恢复文件。