Appropriate Use of Hyper-V Checkpoints
-
With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
-
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
-
@jaredbusch said in Appropriate Use of Hyper-V Checkpoints:
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
Makes sense. When I do maintenance on these normally, I stop IIS once downtime’s been announced, then do my work. So I’d just take the checkpoints at that point. I imagine once stuffs back up and I confirm things aren’t broken, Hyper-V just handles merging the avhdx file in such a way that SQL Server, etc is none the wiser. Or is there significant risk of stuff breaking if it’s running while that merge process takes place?
-
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
@jaredbusch said in Appropriate Use of Hyper-V Checkpoints:
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
Makes sense. When I do maintenance on these normally, I stop IIS once downtime’s been announced, then do my work. So I’d just take the checkpoints at that point. I imagine once stuffs back up and I confirm things aren’t broken, Hyper-V just handles merging the avhdx file in such a way that SQL Server, etc is none the wiser. Or is there significant risk of stuff breaking if it’s running while that merge process takes place?
No real risk. Just performance loss.
-
@scottalanmiller said in Appropriate Use of Hyper-V Checkpoints:
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
@jaredbusch said in Appropriate Use of Hyper-V Checkpoints:
@eddiejennings said in Appropriate Use of Hyper-V Checkpoints:
With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
Makes sense. When I do maintenance on these normally, I stop IIS once downtime’s been announced, then do my work. So I’d just take the checkpoints at that point. I imagine once stuffs back up and I confirm things aren’t broken, Hyper-V just handles merging the avhdx file in such a way that SQL Server, etc is none the wiser. Or is there significant risk of stuff breaking if it’s running while that merge process takes place?
No real risk. Just performance loss.
And never enought to matter to any SMB workload I have ever had to deal with.
