5

I have a 5TB HD and I want to shrink it to 2TB.

I use Google Compute Engine PaaS.

How can I do that?

Can you suggest any tools to perform this manually if this cannot be solved by Google's tools?

Eran Betzalel
  • 367
  • 1
  • 3
  • 11
  • I have this issue as well. I resize2fs the disk to a smaller one but still if I try to clone the disk using a snapshot. I can only create a disk of the original size (or bigger). – RanP Apr 21 '16 at 10:21
  • @RanP was the File System accessible after doing the resize2fs? – George Apr 27 '16 at 19:18
  • Did you try taking a snapshot of the disk, create a disk from that snapshot, attach it to an instance as secondary disk and shrink it. Than use DD to create a new .raw disk, upload it to GCS and create an image from it. Maybe it's worth a try? keep in mind that uploading 2 TB to GCS has charges. https://cloud.google.com/storage/pricing – George May 04 '16 at 13:36
  • I tried dd, It only works if the disks are the same. – RanP May 04 '16 at 13:39

2 Answers2

7

If the disk is not a boot disk you can do the following:

  1. add a new disk with the required size and format it.
  2. mount the new disk
  3. cp -r --preserve=all /mnt/disk1/. /mnt/disk2/
  4. edit the /etc/fstab to mount the new disk instead the old one

If you have standard disk and you want to shorten the cp time. You can first create new ssd disk from snapshot and copy it to 2T ssd disk. Then make a snapshot from the 2T disk and create a new 2T standard disk.

If your disk is a boot disk, you can use a tool like fsarchiver:

  1. Create an archive from the boot disk. fsarchiver savefs /mnt/backup/boot_disk.fsa /dev/sda
  2. Restore the archive on the new disk fsarchiver restfs /mnt/backup/boot_disk.fsa id=0,dest=/dev/sdb
RanP
  • 186
  • 3
  • I spent few days trying fsarchiver tool as instructed to create smaller disk and instance template, but the instances created with this as rootdisk did not start without giving any info in console. So this does not seem to be working. – JaakL Jan 31 '17 at 19:21
  • Did you tried creating instance first (before the template) and then generate an image from the disk (after the shrinking)? – RanP Feb 01 '17 at 08:14
  • I tried instance from template and from disk, both were unbootable. – JaakL Feb 07 '17 at 09:12
  • Can you connect the new disk from the fsarchiver restfs to a working instance as a data disk, and check that the disk is not corrupted? – RanP Feb 08 '17 at 11:38
  • I gave up, the machines seemed unfortunately to be too slow in terms of postgres query response time performance (probably limited io) for my workload compared to some other cloud, even with big empheral ssds. – JaakL Feb 27 '17 at 09:27
  • In google cloud you get IOPS by the size of the disk. What is the size of disk you used, and what machine type? – RanP Feb 27 '17 at 13:26
  • One thing I noticed when going through this is that by default the boot partition on GCP is `/dev/sda1` while these instructions specify `/dev/sda` - I'm trying it out as we speak to see if `/dev/sda` works. As far as performance goes, @RanP is right, you have to use a large disk and specify SSD, then you will get good performance. – ckm Mar 02 '17 at 19:18
0

My answer is very specific to Centos 7 instances on Google's Compute Engine platform. Some information could probably be used out of this for other OS types, but that is beyond my experience.

My use case was shrinking a 400G root device attached to a legacy Centos7 instance back down to 20G. Unfortunately, the root device had just 1 partition (no efi partition), so when I tried fsarchiver, it failed with an error about not able to mount /dev/sdb1 as vfat (sdb1 was the XFS root partition of my target instance, mounted on a shrinker instance).

The process that finally worked for me is as below:

  • Create a new clone instance target-1 (this will have the shrunk disk)
  • Create a temporary instance shrinker-1 (all command prompt actions happen here, running as root).
  • Shut down target-1 and edit it to detach it's root disk (usually named the same as the instance name, BUT lets say 'target-1-root').
  • Connect target-1-root as an extra disk to shrinker-1. This becomes /dev/sdb.
  • Connect a new disk of size 10G greater than disk space required for new boot disk (in my case, 10G base + 10G extra), named target-1-newroot. - this becomes /dev/sdc
  • Initialize a partition table on target-1-newroot similar to target-1-root (MBR or GPT, can be seen via fsdisk -l /dev/sdb, and created using fdisk /dev/sdc)
  • Create the root partition for target-1-newroot (using fdisk) and format it to match target-1-root (xfs for me) using mkfs.xfs /dev/sdc1 (or similar mkfs.$FSTYPE)
  • Create mountpoints: mkdir -p /media/old /media/new
  • mount /dev/sdc1 /media/old (target-1-root)
  • mount /dev/sdb1 /media/new (target-1-newroot)
  • Copy the data : rsync -a /media/old/ /media/new/
  • Save the beginning sectors (start to before the beginning of the first partition) of target-1-newroot:
    • To check: fdisk -l /dev/sdc - this was 2048 for me: 
      Disk /dev/sdc: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x0009c1de

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048    41943039    20970496   83  Linux
    • The sizes should match between the 2 disks (check the partition initialization step before)
  • overwrite the boot sector of /dev/sdc with the boot sector of the old disk using dd if=/dev/sdb of=/dev/sdc bs=512 count=2048 - this is information taken from fdisk -l above.
  • Fix the overwritten partition table back to correct values using fdisk /dev/sdc (fdisk has inline help, use it)
    • delete the bad oversized partition
    • create a new partition with the correct details as above
    • finally set it bootable
  • Check the new root partition UUID (lsblk -o name,uuid) and update it as required:
    • /media/new/etc/fstab
    • /media/new/boot/grub2/grub.cfg
  • umount /media/new
  • Detach target-1-newroot from shrinker-1
  • Edit target-1 and attach target-1-newroot as root device. Also enable the serial console to troubleshoot boot failures if any.
  • Boot up target-1, login and check that things are as expected.

Lastly but no the least, consider sending me a RasPi CM4-${ANY_MMC}-2GB-Wifi using the savings :laugh: .

Samveen
  • 1,869
  • 1
  • 15
  • 19