I want to increase the size of my disk of an instance in Google Compute Engine without losing my current files, how to do in Google Cloud?. I have currently just 10GB and will soon be 100%.
I appreciate any tip. This is the screenshot when I start the terminal:
You can create a snapshot of your current disk. Once done, create a new disk from this snapshot specifying the required size.
If your end goal is to have an instance with the higher size of boot disk than, you can directly create a new instance from this snapshot with the required disk size from developer console, instead of creating the disk and than creating a new instance from this disk.
I hope that helps.
Related
So, I found a file called uma-events under metrics folder in a google compute engine vm(built using Container Optimized OS) which is taking about 5gb space. I cannot extend the partition in the current condition and am running low on disk space. Also, the file mentioned above is owned by chronos(Maybe it is a default user/group?) So, would it be safe to delete the file?
full path of the file is - /mnt/stateful_partition/var/lib/metrics/uma-events
I went through several documentations but didn't find anything useful.
The root file system is mounted as read-only to protect system integrity. However, home directories and /mnt/stateful_partition are persistent and writable.
You can remove it as a temporary solution or you can resize it.
To resolve your issue, do the following:
Create a snapshot of the disk : Make sure that the changes you will do on your instance won't affect your system performance. So that you can easily revert it back to your previous instance state.
Delete files that you don't need on the disk to free up space(Your safe to be removed metrics folder), to learn more about these directories, See Disks and file system overview.
If your disk requires more space after this, resize the disk. (If your VM might become inaccessible if your boot disk is full, to troubleshoot full disk or resize disk refer to this link Troubleshooting full disks and disk resizing.
I have a google cloud compute instance set up but it's getting low on disk space. It looks like it is the /mnt/stateful_partition/var/lib/metrics directory taking up a significant amount of space (3+gb). I assume this is the compute metrics but I can't find any way to safely remove these other than just deleting the files. Is this going to cause any issues?
The path you are referring are File System directories that are used for the GCE VM instance, and you are correct that the metrics folder is safe to be removed. To learn more about these directories, see Disks and file system overview.
I would also suggest to create a snapshot first if you wanted to make sure that the changes you will do on your instance won't affect your system performance. So that you can easily revert it back to your previous instance state.
I am running a wordpress site on google compute engine, it started very well until today......
As the site is intended for user to create contents, I was testing how to increase the size of the persistent disk.
Yes, it is possible and easy, however, it seems not possible to reduce or return to the original size of the disk.
It was 10GB and now it is 10TB, which heavily increased my cost and it is totally unnecessary.
Is there any way that I can reduce the size of the root disk?
I tried to create a new disk from snapshot, but it cannot be attached to the current instance with error "feature not supported".
I think it maybe possible to create a new instance with the snapshot but it will cost me to buy a new SSL cert., however, I guess it could be the last or best option.
Anyone can help?
Thank you so much!
Renfred
I'm pretty sure, you go to options for the instance, and edit them to make sure the "Delete boot disk when instance is deleted" is not selected. This will allow you to delete your current instance. Doing that you can maintain your original IP address etc.
Try to see if that lets you just put the snapshot on a smaller disk without your instance.
From here you can create an image from the disk.
And try to create a new disk from the disk image.
Be sure to have everything backed up etc. Don't delete anything (other then the instance) until you have a working thing back up. And triple check that you won't lose the disk when you trash the instance.
Then when you're back up and running. Make sure you get rid of the stuff you really don't need. You could still have the 10TB disk if you don't delete it. But, avoid that until you have something working again.
In both cases, you would be maintaining the IP address and the webhost. I don't see how that cert no longer matches that. You would be provisioning a new machine in place. Same IP address, same URL, even in the worst cast where you go rid of instance altogether, and start fresh. But, paying 260 bucks a month is a non-starter.
I've been using both for my startup and to me, the functionality is the same. Until now, the instances I've been creating are only for computation. I'm wondering how GCE disk images and snapshots are different in terms of technology, and in which situation it is better to use one over the other.
A snapshot reflects the contents of a persistent disk in a concrete instant in time. An image is the same thing, but includes an operating system and boot loader and can be used to boot an instance.
Images and snapshots can be public or private. In the case of images, public can mean official public images provided by Google or not.
Snapshots are stored as diffs (a snapshot is stored relative to the previous one, though that is transparent to you) while images are not. They are also cheaper ($0.026 per GB/month vs $0.050 for images) (Snapshots are increasing to $0.050/GB/month on October 1, 2022).
These days the two concepts are quite similar. It's now possible to start an instance using a snapshot instead of an image, which is an easy way of resizing your boot partition. Using snapshots may be simpler for most cases.
Snapshots:
Good for backup and disaster recovery
Lower cost than images
Smaller size than images since it doesn't contain OS, etc.
Differential backups - only the data changed since the last snapshot
is recreated
Faster to create than images
Snapshots are only available in the project they are
created (now it is possible to share between projects)
Can be created for running disks even while they are attached
to running instances
Images:
Good for reusing compute engine instance states with new instances
Available across different projects
Can't be created for running instances(unless you use --force flag)
Snapshots are primarily targeting backup and disaster recovery scenarios, they are cheaper, easier to create (can often be uploaded without stopping the VM). They are meant for frequent regular upload, and rare downloads.
Images are primarily meant for boot disk creation. They optimized for multiple downloads of the same data over and over. If the same image downloaded many times, subsequent to the first download the following downloads are going to be very fast (even for large images).
Images do not have to be used for boot disks exclusively, they also can be used for data that need to be made quickly available to a large set of VMs (In a scenario where a shared read-only disk doesn't satisfy the requirements for whatever reason)
Snapshot is a copy of your disk that you can use to create a new persistence disk (PD) of any type (standard PD or SSD PD). You can use the snapshot to create a bigger disk size, also you have the ability of creating the new disk on any zone you might need. Pricing is a bit cheaper for the provisioned space used for a snapshot. when used as backup, you can create differential snapshots.
When you use an existing disk to create an instance, you have to create the instance in the same zone where the disk exists and it will have the size of the disk.
When referring to images resources, is the pre-configured GCE operating system that you’re running (Centos, Debian, etc) and you can use the public images, available for all projects or private images for a specific project or create your own custom image.
A snapshot is locked within a project, but a custom image can be
shared between projects.
simply put - snapshot is basically the backup of the data in the disk
also important point is they are differentially backed up (lesser size).
used for backup and DR mostly.
Image is having backup of the OS as well , custom images are prepared to ensure some organizational policies as well.
In terms of cloud computing - Images are used to launch multiple instances with same configurations and snapshots are mostly for backup
I need to boot about 500 instances with an specific image to do a job with big files that requires POSIX access to more than 10GB. According to that doc https://developers.google.com/compute/docs/images it's impossible create a boot disk of more than 10GB and I need POSIX access to more than 10 GB. Does this mean I will need to create another non-boot disk on each instance with disk space I need? Is there another way to do that?
That doc refers to a limit to the size of the operating system Image, not the size of the boot disk.
You can create a boot disk of any size, and then use it when creating the instance, e.g:
gcutil adddisk "disk-1" --size_gb="15" --zone="europe-west1-b" --source_image="https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/debian-7-wheezy-v20140522"
gcutil addinstance "instance-1" --zone="europe-west1-b" --machine_type="n1-standard-1" --network="default" --external_ip_address="ephemeral" --metadata="sshKeys:" --disk="disk-1,deviceName=disk-1,mode=READ_WRITE,boot" --auto_delete_boot_disk="true"
See: https://developers.google.com/compute/docs/disks#create_disk
You can use Packer to create images on GCE which will auto-resize on boot. I have created a repo specifically for this question which has a demo of an auto-resizing image using recent versions of either Debian-7 backports or container-optimized VM images.
It uses cloud-initramfs-growroot:
automatically resize the root partition on first boot
This package adds functionality to an initramfs built by initramfs-tools. When installed, the initramfs will repartition a disk to make the root volume consume all space that follows it.
You most likely do not want this package unless you know what you are doing. It is primarily interesting in a virtualized environment when a disk can provisioned with a size larger than its original size. In this case, with this package installed, you can automatically use the new space without requiring a reboot to re-read the partition table.
See my script growroot.sh for details and how you can adapt it to your use case.
You have two options:
Create a boot disk larger than 10GB but then you'll need to repartition it, because by default, the provided VM images expand to 10GB so you'll need to use these instructions and run fdisk, reboot, and then run resize2fs to expand the usable space to the full size of the disk. You can automate it so that it runs as part of instance creation by using startup scripts.
Another alternative is to create a separate persistent disk and attach it separately, but then it won't be a boot disk but just a data disk. For that you can use the instructions on the same page, namely:
gcutil adddisk [...]
gcutil attachdisk [...], unless the boot and data disks are added during instance creation via gcutil addinstance --disk=disk1 --disk=disk2 [...], in which case this is not needed
/usr/share/google/safe_format_and_mount [...] to automate the rest
You can easily do this without having to manually resize/partition/format a disk or any of the complications introduced in all the other answers on StackOverflow. Please see my answer here for how this can be done: How to get a bigger boot disk on Google Compute Engine