KVM Backups - DO NOT USE
-
It's very basic. Just full images and automated exports. Nothing extensive. But for firms needing a basic, free backup mechanism, it gets them that. In most cases you would still want something more robust, like StorageCraft, Unitrends or the like. A Veeam product for it would be awesome. But it is enough to get automated data protection in place.
-
@scottalanmiller said in KVM Backups:
It's very basic. Just full images and automated exports. Nothing extensive. But for firms needing a basic, free backup mechanism, it gets them that. In most cases you would still want something more robust, like StorageCraft, Unitrends or the like. A Veeam product for it would be awesome. But it is enough to get automated data protection in place.
See Inbox
-
Qemu has some kind of incremental backup, but I haven't investigated much.
I just want to point out that one advantage to exporting to a raw .img file is that you can mount the image and pull files directly. If you need to import, just have qemu convert the .img back to a .qcow2 file and use the XML dump to rebuild the VM.
-
@scottalanmiller said in KVM Backups:
It's very basic. Just full images and automated exports. Nothing extensive. But for firms needing a basic, free backup mechanism, it gets them that. In most cases you would still want something more robust, like StorageCraft, Unitrends or the like. A Veeam product for it would be awesome. But it is enough to get automated data protection in place.
Is the move away from an agent based backup really worth that much?
Didn't we have this conversation a few months ago?
-
@Dashrender said in KVM Backups:
@scottalanmiller said in KVM Backups:
It's very basic. Just full images and automated exports. Nothing extensive. But for firms needing a basic, free backup mechanism, it gets them that. In most cases you would still want something more robust, like StorageCraft, Unitrends or the like. A Veeam product for it would be awesome. But it is enough to get automated data protection in place.
Is the move away from an agent based backup really worth that much?
Didn't we have this conversation a few months ago?
Unlike a lot of people, I'm fine with agent based. It might not be ideal, but it isn't bad. The big move here, though, is to "free and included."
-
I gotcha... So there is a free and included one in KVM, but no Xen or XS right?
-
@Dashrender said in KVM Backups:
I gotcha... So there is a free and included one in KVM, but no Xen or XS right?
There is a free, included one in Scale and one in XO.
-
Remember, KVM and Xen are base products. They "include nothing" because it would be foolish for anything to exist there. The idea that everything should be built in monolithically is a Windows one. That doesn't make it wrong, it is just one approach and idealistically opposed to all product markets except for Windows. One of the things that the Vmware crowd brags about is how little ESXi does (seriously, they do this.)
Xen and KVM actually do... nothing. It's their support environments that do everything. For Scale, it's the Scale system, not KVM, that does all of the features. With Xen a lot of features come from XenServer and a lot more come from Xen Orchestra. But those things are part of the ecosystem that you get for free. So it kind of feels like they are included, but really they are layered on top, as they should be.
Just like Xen doesn't include DRBD or Gluster or CEPH, but Xen's ecosystem always includes them.
-
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's one thing or a larger company to have a team who's job it is to do just that - Scott's been talking about using Xen for decade plus. I have to assume that Scott the one man who is equal to nearly 10 normal mortals, has managed to collect and put together all of those parts.
The simplicity of XS and XO are what really give Xen any teeth in the SMB market, a la Windows style, everything in one place.
The bad thing about these groupings though, as we found out with the use of VHDs in XS, are the limitations those packages place upon us.
-
@Dashrender said in KVM Backups:
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's hardly chasing down lots of pieces. It's XenServer + Xen Orchestra on one side. Or just Scale on the other.
Compare that to VMware. You need VMware, Starwind, Veeam and how many more components to add up to just one or two in the KVM or Xen worlds? And licensing is the equivalent to many pieces, at least in terms of tracking down and complexity.
Hyper-V isn't quite as bad, but similar. You have Hyper-V confusion, tools for managing Hyper-V, Veeam, Starwind, etc.
The open sources pieces, even though they are separate, are normally bundled more completely than the VMware and Microsoft equivalents.
-
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's hardly chasing down lots of pieces. It's XenServer + Xen Orchestra on one side. Or just Scale on the other.
That's not what I meant.. I mean Xen.. then going and finding all of the other things you need to go along with Xen.
-
@Dashrender said in KVM Backups:
The simplicity of XS and XO are what really give Xen any teeth in the SMB market, a la Windows style, everything in one place.
Here is where I was giving props to XS and XO for bundling things together to make it easier.
-
@Dashrender said in KVM Backups:
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's hardly chasing down lots of pieces. It's XenServer + Xen Orchestra on one side. Or just Scale on the other.
That's not what I meant.. I mean Xen.. then going and finding all of the other things you need to go along with Xen.
But you don't. Just like you don't get ESXi without vSphere. You don't get Xen alone. That's silly.
That's like saying that you went and got the NT kernel and boy is it complicated to build your own windows OS around it. No, you get Windows which is the NT kernel and all the other stuff packaged together.
-
@Dashrender said in KVM Backups:
@Dashrender said in KVM Backups:
The simplicity of XS and XO are what really give Xen any teeth in the SMB market, a la Windows style, everything in one place.
Here is where I was giving props to XS and XO for bundling things together to make it easier.
I see.
-
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's hardly chasing down lots of pieces. It's XenServer + Xen Orchestra on one side. Or just Scale on the other.
That's not what I meant.. I mean Xen.. then going and finding all of the other things you need to go along with Xen.
But you don't. Just like you don't get ESXi without vSphere. You don't get Xen alone. That's silly.
That's like saying that you went and got the NT kernel and boy is it complicated to build your own windows OS around it. No, you get Windows which is the NT kernel and all the other stuff packaged together.
But if you want a Xen solution today that supports VMs with image files larger than 2 TB, you can't use XS, and therefore can't use XO either.. so what is your option then?
Sure you can bandaid it with spanning, but come on, should that really be required?
-
@Dashrender said
But if you want a Xen solution today that supports VMs with image files larger than 2 TB, you can't use XS, and therefore can't use XO either.. so what is your option then?
Have less data.
(JOKE.)
-
When XO grows up to be more fully functional, then I will consider replacing Hyper-V with XS.
The potential in XO is awesome, but it is too much work for not enough of a return still.
Hyper-V + Veeam is solid, well known, and handles everything needed.
Ignore the "confusion" comment @scottalanmiller made because it exists with all hypervisors in the SMB.
Also, Starwind (good product, but) is a waste in the SMB. Very few need more than a single server. The few that do, can then just get by with Hyper-V replication for their pseudo fail over needs.
-
@Dashrender said in KVM Backups:
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
@scottalanmiller said in KVM Backups:
@Dashrender said in KVM Backups:
You're right.. I have to keep reminding myself of that. But SMB's don't want to be chasing down dozens of little pieces all over the place to make these pieces work.
It's hardly chasing down lots of pieces. It's XenServer + Xen Orchestra on one side. Or just Scale on the other.
That's not what I meant.. I mean Xen.. then going and finding all of the other things you need to go along with Xen.
But you don't. Just like you don't get ESXi without vSphere. You don't get Xen alone. That's silly.
That's like saying that you went and got the NT kernel and boy is it complicated to build your own windows OS around it. No, you get Windows which is the NT kernel and all the other stuff packaged together.
But if you want a Xen solution today that supports VMs with image files larger than 2 TB, you can't use XS, and therefore can't use XO either.. so what is your option then?
Sure you can bandaid it with spanning, but come on, should that really be required?
I'm of the opinion as well that this is ridiculous. But I was speaking to internal engineering at Scale yesterday and mentioned this and while they don't have these limits, they echoes @DustinB3403 that they felt having single volumes a lot larger than 2TB was not a good idea either.
-
@JaredBusch said in KVM Backups:
Also, Starwind (good product, but) is a waste in the SMB. Very few need more than a single server. The few that do, can then just get by with Hyper-V replication for their pseudo fail over needs.
I totally agree with the idea that most only need one server and the others can use the Hyper-V replication. My thought there is that Starwind is free at that scale and does it better than the Hyper-V replication model, so is worth using. Not required, but still valuable.
-
@JaredBusch said in KVM Backups:
When XO grows up to be more fully functional, then I will consider replacing Hyper-V with XS.
The potential in XO is awesome, but it is too much work for not enough of a return still.
Hyper-V + Veeam is solid, well known, and handles everything needed.
Ignore the "confusion" comment @scottalanmiller made because it exists with all hypervisors in the SMB.
> Also, Starwind (good product, but) is a waste in the SMB. Very few need more than a single server. The few that do, can then just get by with Hyper-V replication for their pseudo fail over needs.
W/out knowing RTO and RPO whole phrase above is a pure speculation and IMHO. Size of the business is a very flaky indicator of an uptime requirements and how much data can be lost: there are 500+ seat Enterprises who can live with their production servers down and they keep going (one of our customers is outsourcing company here, devs have their own copy of source code locally so can keep coding with a source trunk and file services down for a few hours, they can also tolerate data loss because they can a) re-implement and b) recover from local copies) and there are small "Mom and Dad" shops with only 4 employees (not even SMBs, these are uber-small-B's) who don't do well even with a few minutes of downtime (another customer of us, 3D printing and laser cutting facility, these guys live from what they do today). Either way: make your decisions being driven by NUMBERS and not by EMOTIONS and OPINIONS or you'll get yourself DOOMED.
P.S. Also people who recommend Hyper-V Replica for uptime improvement usually never used one for more then a couple of VMs (if used at all). Using DR instead of a BC is LOL.
