Сайт полностью отключился после изменения размера загрузочной дискеты ВМ (Google Cloud) - PullRequest
1 голос
/ 20 марта 2019

Мне пришлось изменить размер загрузочного диска моей виртуальной машины Debian Linux с 10 до 30 ГБ, потому что он был заполнен.После этого и остановки / запуска моего экземпляра он стал бесполезным.Я не могу войти в 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, затем размонтировал его снова.(поэтому я отредактировал fstab, fstab.backup и т. д.)

Ничего из того, что касается изменения размеров дисков / таблиц перераспределения в облачной документации Google, не помогло мне. growpart, fdisk, resize2fs имногие другие сообщения StackOverflow не делали ни одного.

При попытке получить доступ через SSH я получаю сообщение об ошибке «Невозможно подключиться через порт 22», как указано здесь в облачных документах Google

При создании нового экземпляра Debian Linux с новым диском он работает нормально.

Любой, кто сможет это запустить и запустить для меня без потери каких-либо данных, получит 100+ и МНОГО ЛЮБВИ ......

1 Ответ

1 голос
/ 20 марта 2019

Я пытался повторить сценарий случая, но он не вызвал у меня проблем с экземпляром виртуальной машины.

Я создал экземпляр виртуальной машины с 10 ГБ данных, а затем остановил его, увеличил размер диска до 30 ГБ и снова запустил экземпляр. Вы упоминаете, что не можете подключиться к экземпляру или получить доступ к своему приложению. После моего теста я мог ssh, хотя и войти в экземпляр. Таким образом, должна быть проблема процедуры, которую вы выполнили, которая повредила экземпляр виртуальной машины или, возможно, загрузочный диск.

Однако существует обходной путь для восстановления файлов из экземпляра, к которому вы не можете подключиться по SSH. Я проверил это, и у меня это сработало:

  1. Перейдите на страницу Compute Engine, а затем перейдите к Images
  2. Нажмите «[+] СОЗДАТЬ ИЗОБРАЖЕНИЕ»
  3. Дайте этому изображению имя и под Source выберите Disk
  4. В разделе Source disk выберите диск экземпляра виртуальной машины, размер которого вы изменили.
  5. Нажмите Save, если виртуальная машина диска работает, вы получите сообщение об ошибке. Сначала остановите экземпляр виртуальной машины и повторите те же действия, либо просто установите флажок Keep instance running (not recommended). (Я бы порекомендовал сначала остановить его, что также указывало на ошибку).
  6. После сохранения нового созданного изображения. Выберите его и нажмите + CREATE INSTANCE
  7. Дайте этому экземпляру имя и оставьте все настройки без изменений.
  8. В разделе Boot Disk вы убедитесь, что видите размер 30 ГБ, который вы установили ранее, когда увеличивал размер диска, и имя должно быть именем созданного вами образа.
  9. Нажмите кнопку «Создать» и попробуйте выполнить SSH к вновь созданному экземпляру.
  10. Если все ваши файлы были сохранены при изменении размера диска, вы сможете получить доступ к последним файлам, которые были у вас до повреждения ВМ.

ОБНОВЛЕНИЕ 2-Й РЕШЕНИЕ - ПОДКЛЮЧИТЕ ДИСК ЗАГРУЗКИ В КАЧЕСТВЕ СРЕДИ ДРУГОЙ ИНСТАНЦИИ ВМ

Чтобы подключить диск из поврежденного экземпляра виртуальной машины к новому экземпляру GCE, вам необходимо выполнить следующие шаги:

  1. Перейдите на Compute Engine > Snapshots и нажмите + CREATE SNAPSHOT.
  2. В разделе Source disk выберите диск поврежденной виртуальной машины. Создайте снимок.
  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. Тогда вы сможете загрузить все файлы с диска. Я проверил это сам, и я мог восстановить файлы со старого диска с помощью этого метода.
...