I am using Google Compute Engine VM for a web server. I currently have 3TB as disk space but want to bring it down to 1TB. Can someone tell me where I can do this from? Thanks.
As #John Hanley only increasing disk size is supported by Google Cloud:
gcloud compute disks resize resizes a Compute Engine disk(s).
Only increasing disk size is supported. Disks can be resized regardless of whether hey are attached.
I also found an answer in Serverfault that could help you with this topic here.
It uses fsarchiver tool in order to manage the boot disk resizing:
If the disk is not a boot disk you can do the following:
add a new disk with the required size and format it.
mount the new disk
cp -r --preserve=all /mnt/disk1/. /mnt/disk2/
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:
Create an archive from the boot disk. fsarchiver savefs /mnt/backup/boot_disk.fsa /dev/sda
Restore the archive on the new disk fsarchiver restfs /mnt/backup/boot_disk.fsa id=0,dest=/dev/sdb
I am looking for details about what is the actual difference between image and snapshot. Let us say, I have an instance running on Redhat OS and Apache webserver. If I create an image and snapshot exactly at the same time. What will be the content of an image compared to the snapshot? Let's assume a snapshot is taken when the instance was shut down.
Snapshots:
Reduced cost and faster to create than images
Easiest way for data backup and disaster recovery
Smaller size than images as there is no OS
Differential backups - only contains changed data that are different since last snapshot [click here]
Can be created for running disks even while they are attached to running instances
Create snapshot schedules to automatically backup your data.
Cost involved if you create snapshot in other location than the source disk
Snapshot will be encrypted as per disk encryption settings
Creating instance from snapshot is little slower than creating from images
Images:
Available across different projects click here
Creating image for running machine is not recommended
Images on GCP are pre-configured operating system, however, you can also create your own custom image
Good for reusing compute engine instance states with new instances
You can select encryption management solution during custom image creation
At the moment I have one boot disk with size of 10 GB. For what I see google it cost me $1.70 per / month , which mean it's a type "SSD provisioned space" ( $0.170 per GB/Month).
I want to use type "Standard provisioned space" which is $0.040 per GB/Month .
i.e for 100 GB the price is $4 vs $17
Is it possible to set boot disk to be "Standard provisioned space" and resize it to 100 GB , or I need to add new disk from type "Standard provisioned space" ?
You will need to create a new disk.
You can migrate the content of the current disk to the new disk following the next steps.
Create snapshot of the persistent disk.
Create a new standard disk from the snapshot.
At this point you have two choices:
Create a new instance with the SSD disk as a boot disk, unassign the static IP from old instance and attach it to the new instance. Once done delete the old instance. This will have has less or almost no downtime.
Delete the old instance, create a new instance with the new disk and assign the static IP. This will reduce the cost but will have downtime.
(Source: Change Google Compute/Cloud Server to SSD Persistent Disk)
I want to launch an instance with custom size of root volume on Amazon EC2.
At step no.4 - Add Storage, the root volume default setting came with a default snapshot and a default 10 size (GiB). Then I lowered the size into 5GiB.
But at the final step, it wouldn't allow me to launch the instance because of only 5GB root volume.
Any idea or solution that I can lower the size when launching an instance?
You cannot create an Amazon EBS volume that is smaller than the snapshot that you want loaded.
You could attempt to make your own AMI by launching with 10GB, attaching a 5GB volume, copying files across, turning it into an AMI, etc but frankly it isn't worth the bother.
If you are merely wishing to save money, then at 10¢ per GB per month, it would only save 50¢ per month.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm quite impressed with Amazon's EC2 and EBS services. I wanted to know if it is possible to grow an EBS Volume.
For example: If I have a 50 GB volume and I start to run out of space, can I bump it up to 100 GB when required?
You can grow the storage, but it can't be done on the fly. You'll need to take a snapshot of the current block, add a new, larger block and re-attach your snapshot.
There's a simple walkthrough here based on using Amazon's EC2 command line tools
You can't simply 'bump in' more space on the fly if you need it, but you can resize the partition with a snapshot.
Steps do to this:
unmount ebs volume
create a ebs snapshot
add new volume with more space
recreate partition table and resize
filesystem
mount the new ebs volume
Look at http://aws.amazon.com/ebs/ - EBS Snapshot:
Snapshots can also be used to instantiate multiple new volumes,
expand the size of a volume or move
volumes across Availability Zones.
When a new volume is created, there is
the option to create it based on an
existing Amazon S3 snapshot. In that
scenario, the new volume begins as an
exact replica of the original volume.
By optionally specifying a different
volume size or a different
Availability Zone, this functionality
can be used as a way to increase the
size of an existing volume or to
create duplicate volumes in new
Availability Zones. If you choose to
use snapshots to resize your volume,
you need to be sure your file system
or application supports resizing a
device.
I followed all the answer, all have something missing with all respect.
If you follow these steps you can grow your EBS volume and keep your data (this is not for the root volume). For simplicity I am suggesting to use AWS consule to create snapshot,... you can do that using AWS command line tools too.
We are not touching the root volume here.
Goto your AWS console:
Shutdown your instance ( it will be for a few minutes only)
Detach the volume you are planning to grow (say /dev/xvdf)
Create a snapshot of the volume.
Make a new volume with a larger size using the snapshot you just created
Attach the new volume to your instance
Start your instance
SSH to your instance:
$ sudo fdisk -l
This gives your something like:
Disk /dev/xvdf: 21.5 GB, 21474836480 bytes
12 heads, 7 sectors/track, 499321 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd3a8abe4
Device Boot Start End Blocks Id System
/dev/xvdf1 2048 41943039 20970496 83 Linux
Write down Start and Id values. (in this case 2048 and 83)
Using fdisk ,delete the partition xvdf1 and create a new one that starts exactly from the same block (2048). We will give it the same Id (83):
$ sudo fdisk /dev/xvdf
Command (m for help): d
Selected partition 1
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-41943039, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-41943039, default 41943039):
Using default value 41943039
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
This step is explained well here: http://litwol.com/content/fdisk-resizegrow-physical-partition-without-losing-data-linodecom
Almost done, we just have to mount the volume and run resize2fs:
Mount the ebs volume: (mine is at /mnt/ebs1)
$ sudo mount /dev/xvdf1 /mnt/ebs1
and resize it:
$ sudo resize2fs -p /dev/xvdf1
resize2fs 1.42 (29-Nov-2011)
Filesystem at /dev/xvdf1 is mounted on /mnt/ebs1; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/xvdf1 to 5242624 (4k) blocks.
The filesystem on /dev/xvdf1 is now 5242624 blocks long.
ubuntu#ip-xxxxxxx:~$
Done! Use df -h to verify the new size.
As long a you are okay with a few minutes of downtime, Eric Hammond has written a good article on resizing the root disk on a running EBS instance: http://alestic.com/2010/02/ec2-resize-running-ebs-root
All great recommendations, and I thought I'd add this article I found, which relates to expanding a Windows Amazon EC2 EBS instance using the Amazon Web UI tools to perform the necessary changes. If you're not comfortable using CLI, this will make your upgrade much easier.
http://www.tekgoblin.com/2012/08/27/aws-guides-how-to-resize-a-ec2-windows-ebs-volume/
Thanks to TekGoblin for posting this article.
You can now do this through the AWS Management Console. The process is the same as in the other answers but you no longer need to go to the command line.
BTW: As with physical disks, it might be handy to use LVM; ex:
http://www.davelachapelle.ca/guides/ubuntu-lvm-guide/
http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/
Big advantage: It allows adding (or removing) space dynamically.
It can also easily be moved between/among instances.
Caveats:
it must be configured ahead of time
a simple JBOD setup means you lose everything if you lose one "disk"
My steps:
stop the instance
find the ebs volume attached to the instance and create a snapshot of it
create a new volume with bigger disk space using the above snapshot. Unfortunately the UI on the aws console to create a snapshot is almost unusable because it's listing all the snapshots on aws. Using command line tool is a lot easier, like this:
ec2-create-volume -s 100 --snapshot snap-a31fage -z us-east-1c
detach the existing ebs (smaller) volume from the instance
attach the new (bigger) volume to the instance, and make sure attach it to the same device the instance is expecting (in my case it is /dev/sda1)
start the instance
You are done!
Other than step 3 above, you can do everything using the aws management console.
Also NOTE as mentioned here:
https://serverfault.com/questions/365605/how-do-i-access-the-attached-volume-in-amazon-ec2
the device on your ec2 instance might be /dev/xv* while aws web console tells you it's /dev/s*.
Use command "diskpart" for Windows OS, have a look here : Use http://support.microsoft.com/kb/300415
Following are the steps I followed for a non-root disk (basic not dynamic disk)
Once you have taken a snapshot, dismounted the old EBS volume (say 600GB) and created a larger EBS volume (say 1TB) and mounted this new EBS volume - you would have to let Windows know of the resizing (from 600GB to 1TB) so at command prompt (run as administrator)
diskpart.exe
select disk=9
select volume=Z
extend
[my disk 9,volume labelled Z, was a volume of size 1TB created from an ec2-snapshot of size 600GB - I wanted to resize 600GB to 1TB and so could follow the above steps to do this.]
I highly recommend Logical Volume Manager (LVM) for all EBS volumes, if your operating system supports it. Linux distributions generally do. It's great for several reasons.
Resizing and moving of logical volumes can be done live, so instead of the whole offline snapshot thing, which requires downtime, you could just add create another larger EBS volume, add it to the LVM pool as a physical volume (PV), move the logical volume (LV) to it, remove the old physical volume from the pool, and delete the old EBS volume. Then, you simply resize the logical volume, and resize the filesystem on it. This requires no downtime at all!
It abstracts your storage from your 'physical' devices. Moving partitions across devices without needing downtime or changes to mountpoints/fstab is very handy.
It would be nice if Amazon would make it possible to resize EBS volumes on-the-fly, but with LVM it's not that necessary.
if your root volume is xfs file system then then run this command xfs_growfs /