Restoring a VM to snapshot
There is a VM on GCP.
We will take a snapshot of the disk of that VM. And name it as Restore point 1.
Now after 10 days I want to take my system back to Restore point 1.
There is no way of doing that.
Only one way around is to delete this Instance and create new instance with the Snapshot taken. This can lead to following issues- Internal IP address might change. So to resolve this issue, there should be some feature by which one can restore the machine to an older date
We’ve just released a feature to GA which allows you to detach and re-attach boot disks to GCE VMs.
Using this feature, you may now restore a VM from snapshot by:
1. Stopping the instance – (e.g. gcloud compute instances stop INSTANCE_NAME —zone INSTANCE_ZONE)
2. Detaching the boot disk from the VM in question ($ gcloud compute instances detach-disk INSTANCE_NAME —disk DISK_NAME —zone INSTANCE_ZONE)
2. Creating a disk from the snapshot in question
3. Attaching the disk from step 2 to the VM as the boot disk ($ gcloud compute instances attach-disk INSTANCE_NAME —disk NEW_DISK_NAME —boot —zone INSTANCE_ZONE)
After restore, the VM will keep its IP address and other properties (e.g. tags, labels, etc.).
See more info about the feature in the docs:
Down the road, we’re also planning to improve this flow to be “one-click easy.” More updates to come.
I am also very shocked this "one click" solution is still not available. The concept of snapshots in GCP are misleading, making you think you can revert an instance at any point in time, when in reality all you have is a ***disk*** snapshot that is only useful in a brand new instance (unless if you use the command lines instructions pointed out above, which are not intuitive nor documented).
I am just shocked that this is not implemented in GCP. This is just 2 clicks on vSphere.
Thanks for the feedback, Josef. I'll make sure Sirui sees it and we'll continue improving this functionality.
Note, we do hope to add a one-step ability to restore-reboot to an earlier snapshot, but we're providing the underlying functionality first, since there is another use case where a disk needs to be detached so it can be mounted as a data volume on another VM in order to make manual repairs (say, if the disk becomes unbootable for some reason).
Josef Cook commented
I can confirm that the Beta feature for detaching and reattaching a boot disk to an instance does indeed work. Note that you will need to stop the VM instance prior to running any gcloud "detach-disk" commands.
Another note not mentioned by @siruisun nor covered in the docs at the provided link: I was prompted for region during the detach-disk command. Using the provided default region (which did not match my instance region) failed. I had to enter "n" to allow the command to complete using the detected region (which it displayed following the prompt and I verified as correct).
This is good news!
RVJ Callanan commented
I have just encountered this problem and I am gobsmacked.
There is no excuse for this.
It is fundamental to any server deployment (Cloud-based or otherwise).
It should be a simple sequence:
- Shut down VM
- Restore snapshot to boot disk
- Optionally restore snapshot to any other non-boot disks
- Restart server
This should be a cinch for Google to implement.
And it is an absolute necessity.
I have a feeling it may be complicated by interim changes to VM settings, e.g. external IP address or Microsoft licensing issues (hence the current requirement to restore to a new VM instance).
Well, IMHO, that should be the customer's worry, not Google's
If I were to change any external settings, I would first carry out the following procedure:
- Restore VM from previous snapshot (to ensure a clean predictable base)
- Make the required VM settings changes
- Reboot and test
- Make a new snapshot
Please, Google, get this sorted ASAP.
Like many others, I have put a massive effort into embracing Google Cloud.
Many clients using legacy Windows applications are lined up for Compute Engine.
I was even lulled into a false sense of security by the availability of snapshot functionality.
But when I attempted to perform a restore, I came across this problem.
This is more than just "appalling", it is contemptible.
Apart from the time-wasting aspect, restoring to a new VM unleashes other issues
Especially with Windows Server.
I will give Google until the end of the month to sort this.
Otherwise I'm moving lock, stock and barrel to Amazon.
Juan Romero commented
"As with any software company, we have a fixed number of engineers that can work on new features and functionality at any given time. The fact that we haven't done something requested here doesn't mean it is "technically challenging" per se, but often simply means that we have prioritized other customer-requested items ahead of it."
Okay, you seem to be not understanding all of us here, and I'm going to repeat what I stated earlier.
THIS FEATURE SHOULD BE **TOP PRIORITY** FOR YOUR TEAM. Restoring from backups quickly and simply on VM's is such a basic feature that it's like an OS releasing without a network stack. It's been 8 months since I last posted this and your team is only *now* considering implementing this. Not good enough.
ALL engineers working on feature requests should be on this *now*. It doesn't help that the documentation for restoring from snapshots is vague at best either - clearly they know that how it's currently set up is stupid. I am with holding all major upgrades to our VM's simply because the downtime required to restore from backups is just too long on GCE and will cost us too much per minute. But if it doesn't get resolved by the end of this year, I will be forced to migrate to other solutions.
Honestly, this is Google we're talking about here, not some startup company getting their bearings. I'm appalled at how this has been handled.
you have got to be ******* kidding me...a multi billion dollar company cant setup this?
Thanks Google you dumb *******, you have just ********* what should be an easy task for me...i need to rollback my server just 24 hours because a website without a backup was deleted.
As with any software company, we have a fixed number of engineers that can work on new features and functionality at any given time. The fact that we haven't done something requested here doesn't mean it is "technically challenging" per se, but often simply means that we have prioritized other customer-requested items ahead of it. We appreciate your desire to have this feature, and hope we can deliver it as soon as possible.
Martin Levasseur commented
Google, any updates on this? Why is this such a technical challenge, I wonder
I've been looking for this feature and found this article. Wow! not YET?
This feature must have for the test purpose.
I test the production server and create a test server every time with the annoying configurations.
What a waste of time.
Please add this feature as TOP priority.
Also, please SQL improvement.
Carlos Ruiz commented
can I at least mount the snapshot?
Alex Bender commented
This is sort of ridiculous this doesn't already exist. Please create this immediately.
I just voted for this as well. This feature is a must and Azure has this, I believe AWS does as well.
An easy way to restore a VM snapshot while keeping the same configuration, IPs, boot scripts and syncing up with Deployment Manager is much needed. Currently, if you have used the Deployment Manager, take a snapshot and fire up as a new VM, the VM instance is not anymore part of the deployment. It would be much faster and easier (especially for less technical users) to be able to simply restore the snapshot of a VM within a deployment and avoid any further configuration of IPs, DNS, security, etc.
[Deleted User] commented
Yikes! This is crazy. This is sort of the purpose of VMs.....
As a new "possible" customer, I'm a little shocked to read about this shortcoming. I always kinda thought this was one of the main points of taking a snapshot.
9KSoft Cloud Software Services commented
Cmmon google you can do it!!!
What is the status of this?
looks like you guys are about lose 17 accounts. All from this one pathetic and completely ignorant shortcoming. I need to restore a backup on a simple wordpress install and now realize this has taken away 2 hours of my day and I still have about 3 hours of work to get this stupid thing working again. Terrible. Use another platform.