Shrinking a Volume on an AWS EC2 Windows Server

• Posted by:
• Olly Lennox
• 1 Comment

Introduction

There are various guides online for shrinking a volume for a Linux based EC2 instance but I recently had to do this for a Windows instance which seems to be a path less travelled. I’ve not covered every single step in detail but hopefully there is enough information to get you through it.

The general process is to create a new volume of the desired (smaller) size, migrate the data across using the instance itself, then attach the new volume as the primary/active volume to the instance (replacing the old volume).

Make a backup

Before you go any further it’s important to make sure you have a backup / snapshot of your instance so you can roll back in the event of any problems. You can delete these at the end when everything is working but it’s vital that you backup before proceeding any further.

Amazon Encryption / Bit Locker

These steps all assume that you’re not using encryption on your Amazon instances/volumes. There is a chance that it will all still work but I’ve not tested it so proceed at your own risk. If you have Bit Locker enabled on the instance then I strongly recommend you disable it and fully decrypt the partition/s first. Once you’ve moved across you can re-enable it again.

In-Place vs Offline Migration

We have two options for migrating the volume:

• Create a new, smaller volume and then copy the data across ‘in-place’
  
  
• Create two new volumes – a smaller one and a clone of the active volume – and then copy the data across ‘offline’
  
  

The first option is quicker because its just a single copy operation but VSS will need to be fully working on the Windows environment and you must be confident that all of the apps you’re running are fully VSS compatible. You can find more information on VSS here:

https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service

If you’re at all unsure about this, or if you want to be 100% sure on a clean copy then I’d recommend going with the second option which will take longer to copy but if done correctly will have no chance of data corruption.

I’ll cover both approaches below.

Shrinking the active partition/s

We need to be sure that the partitions on the current volume will fit onto the new, smaller volume. You will need to examine all of the partitions to make sure that they are small enough to fit and shrink them down if they are too big.

I’m not going to go into depth here about how to shrink partitions but refer to the following Microsoft guide on how you can do this from Windows:

https://learn.microsoft.com/en-us/windows-server/storage/disk-management/shrink-a-basic-volume

Often the built-in Windows tool can only shrink so much but there are third-party tools (like MiniTool partition wizard) which can sometimes do a better job (below).

https://www.partitionwizard.com/resizepartition/free-shrink-windows-partition.html

Be careful when making changes to your main Windows and System partitions though as a cock-up here might corrupt your data and/or cause your AWS instance not to boot.

It might also not be possible to shrink the Windows partition while in use. In which case you will have to take approach 2 and clone the active volume first, then shrink the partitions on the clone.

Approach 1: Migrating a volume “In-Place”

Head to the Volumes tab in EC2 and create yourself a new volume of the desired (smaller) size and configuration in the same region as your instance. Then attach this volume as a data/secondary partition to your instance.

The new drive should show up in windows under Disk Management (in Computer Management). It won’t be initialized yet so it probably won’t have a drive letter or any partitions.

You will need to use a third-party tool to copy the partition/s over from the current active volume to your new, smaller volume. Macrium Reflect worked well for me and they offer a free trial (below) but use whichever partition/disk image software you prefer.

https://www.macrium.com/reflectfree

It may take a few hours to copy so be patient and leave it to do its thing.

Approach 2: Migrating a volume “Offline”

You should already have a backup Snapshot of your instance from the earlier steps but if not, head to your instance in EC2 and take a new Snapshot of it. Once the snapshot has completed, head to the Snapshots tab and copy down the unique name of it

Next, head to the Volumes tab and create a new Volume of the same size/configuration as your current volume. E.g. if you current volume is 500gb, make this one a 500gb volume. In the creation page there is an option to specify a snapshot for the volume. Choose “Custom Snapshot” and paste in the unique id/name of your backup snapshot.

Mount this volume to your AWS instance as a data/secondary partition. The volume should show up in the instance as a new drive and be assigned one (or more) drive letters so If you need to shrink your partitions on the cloned volume then you can do this now.

Follow the steps from Approach 1 to create your smaller volume and attach this to the instance in the same way. Make sure to keep track of all your volumes and drive letters now as you don’t want to overwrite the wrong volume by mistake.

Follow the steps in Approach 1 to copy across your partitions from the cloned drive to your new, smaller volume. You don’t have to worry about VSS or copying from running apps so any old partition manager will do for this like MiniTool Partition Wizard (below)

https://www.partitionwizard.com/free-partition-manager.html

When you create a volume from a snapshot it has to “instantiate” every block which is a very slow process. Because of this, the copy job could potentially take a very (very) long time so you may need to run it overnight or over a weekend.

Once the copying is all done, I’d  recommend detaching the cloned volume so you are left with just the active volume and the smaller volume. This will help you avoid drive letter confusion in the next steps.

Get it to boot

If you try to use your new volume with the instance at this point then you will likely find that it never boots up. Although you have copied all the data across, you will need to sort out the BCD and the boot sector before it will all work.

The default method of booting is MBR / Legacy (or “BIOS”)  but your instance might be set to EFI / GPR. If you only had 1 partition to copy then it’s likely to be MBR whereas if you had to copy a little System or EFI partition too then it will be EFI. You can check this in the instance settings in EC2.

 I’ll cover both below

MBR Booting

Your newly minted volume should have be allocated a new drive letters in Windows so note this down. For this example I will be using the drive letter D:\ as my smaller volume but substitute in your own.

Open an elevated command prompt.

First we will initialize the boot sector on the new volume:

> bootsect /nt60 D: /mbr

This command creates a master code on D: that is compatible with Windows 8 / Server 2012 or newer. For full details refer to the following article:

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/bootsect-command-line-options?view=windows-11

Note that some versions of Windows Server don’t include the bootsect tool. If you are receiving a “command not found” message then you will need to copy the tool over from your own PC (it’s stored under C:\Windows\System32\bootsect.exe

Next we will clear out the existing boot records that have been copied over from the old drive

> bcdedit /store D:\boot\bcd

This command should list all of the current boot records on the D: drive. It’s very important you use the /store switch otherwise you will be editing the BCD on your active partition which will break your instance

> bcdedit /store D:\boot\bcd /delete {default} /f

Use this command to trash out all of the entries in the BCD, replacing “{default}” with the name of each entry. Once you done, the list command should show that the BCD is empty with zero entries

> bcdboot d:\windows /s d: /f BIOS

Finally this command will recreate our boot entries on drive D: specifying d:\windows as the target OS. Obviously if your Windows directory has a different name then substitute this instead. The BIOS switch tells it to create MBR compatible records.

EFI Booting

The process is similar to MBR but instead of just targeting the Windows partition, some of the commands will instead need to target your system/EFI partition that you also copied across. For this section I will refer to D: as my Windows partition and S: as the system partition (on the new, smaller volume). Substitute these letters with your own.

> bootsect /nt60 S:

In this case we’re targeting the system partition S: instead to make it bootable. Note that we’ve dropped the /mbr switch.

> bcdedit /store S:\EFI\Microsoft\Boot\BCD

If you get an error here, use Windows Explorer or the command prompt to double check the location of the BCD file on your EFI/System partition (I’ve not tested this on AWS so they might use a slightly different folder structure)

> bcdedit /store S:\EFI\Microsoft\Boot\BCD /delete {default} /f

As before, trash out all entries in the BCD

> bcdboot d:\windows /s s: /f UEFI

Note that in this case we are specifying the S: drive as the BCD location and we are using “UEFI” mode on the /f switch. As before, replace d:\windows with your own Windows’  folder name.

Check it works

Shutdown the instance and detach all Volumes, then attach your new small volume as the primary/active Volume using the /dev/sda1 parameter.

Fire up the instance and hooray, you should be up and running on a smaller volume.

If the instance hasn’t started after a few minutes then most likely it has been unable to boot. You will need to stop the instance, detach the new volume, reattach the old volume on /dev/sda1 and reattach the new volume again as a data/secondary drive.

If your instance fails to boot on the old volume then uh oh. It is likely that you messed up one of the steps above and screwed up your active volume. You will need to restore this volume from your backup snapshot.

Once you’re back into the instance on the original volume you will need to figure out why your new drive isn’t booting:

• Make sure your copy was clean and you haven’t corrupted your partitions on the new volume
  
  
• Make sure your shrink worked correctly – if you cloned the drive then check to see if this volume boots correctly (it should just work without changes to BCD if you created it from a snapshot)
  
  
• Double check your bcd commands from the previous steps and make sure your BCD is getting correctly setup on the new volume.
  
  
• You can use a third-party partition editor tool to make sure that the partitions are setup correctly with the right flags
  
  
• If using MBR, make sure your partition is marked “ACTIVE”. This should have been done as part of the above steps but you can use the DISKPART commandto do it manually
  

I hope this helps, if you need support managing your business assets in AWS cloud then don’t hesitate to drop us a call.