Converting to a virtual environment
-
@scottalanmiller said
And my sentiment being that it was only people doing non-standard things and those following the instructions and keeping it simple (with the exception of needing to skip the SD piece) it's rock solid. Is anyone having issues with normal usage? I'm not aware of a stability concern. And also I pointed out that the things that cause the "instabilities" as they are seen will do the same things on Hyper-V... so the issue isn't about XenServer, it's about people pushing boundaries on test boxes to see what breaks and where.
I ain't touchin' nothing' no mores.
(Though I am going to keep testing my /var/log theories.)
-
@scottalanmiller said in Converting to a virtual environment:
At 90 minutes, a good backup system can almost always restore your VMs in that window. It require the backup system to be able to push a restore that quickly AND your servers to be able to ingest a restore that quickly. So a lot of ifs, but it can be done and might be the cheapest path to your goal. You still use virtualization to make the "magic" happen on this, but using the storage of the two nodes to handle this is only one option, using the backup system to get rapid backups and rapid restores is a very viable approach when you don't need to recover "in seconds."
So, you're saying that one can backup all VMs(Data n all), onto an external media, and when the Primary host goes down, the VMs can be restored onto the secondary host ...
Our current backup scenario is rather straight-forward... We use a backup Software (called Easus) to perform daily incremental backups (at EOD), with 1 weekly full-backup. This has worked well for us (Tried n Tested)
So, going by what you're suggesting, can we incrementally (Every 30 mins) backup the VMs to the same USB drive, but this time, using a VM specific backup solutions such as Veeam Free...
Also, with something like Veeam Free, does the backup source host & restore target host have to be the same ? While restoring, can I just select another host as the restore target, and boom, it'd be up n running ?
Also, how long would be take to restore a 1TB VM ?
-
@BRRABill said in Converting to a virtual environment:
@scottalanmiller said
And my sentiment being that it was only people doing non-standard things and those following the instructions and keeping it simple (with the exception of needing to skip the SD piece) it's rock solid. Is anyone having issues with normal usage? I'm not aware of a stability concern. And also I pointed out that the things that cause the "instabilities" as they are seen will do the same things on Hyper-V... so the issue isn't about XenServer, it's about people pushing boundaries on test boxes to see what breaks and where.
I ain't touchin' nothing' no mores.
(Though I am going to keep testing my /var/log theories.)
It's good for testing. Just don't compare issues when you are trying to break things with stability issues. Or if you do, test them equally across platforms. I know of no one testing Hyper-V in a similar fashion.
-
@PRPL said in Converting to a virtual environment:
So, you're saying that one can backup all VMs(Data n all), onto an external media, and when the Primary host goes down, the VMs can be restored onto the secondary host ...
Yes, that's the idea. If the backup server, network and host node are fast enough, you can restore in 90 minutes (or less.)
-
@PRPL said in Converting to a virtual environment:
Also, with something like Veeam Free, does the backup source host & restore target host have to be the same ? While restoring, can I just select another host as the restore target, and boom, it'd be up n running ?
No, does not need to be the same. Although Veeam Free will leave you without some of the things that you want. Unitrends or XenOrchestra will likely do a better job for you here when trying to do this for free.
-
@PRPL said in Converting to a virtual environment:
Also, how long would be take to restore a 1TB VM ?
Depends on a lot of things. This is an actual 1TB of data on the VM, not the size before compression?
Let's start with the network bottleneck.. If your network for backups (and restores) is 100% dedicated, the pretty much the fastest possible 1TB restore will be two and a half hours on a GigE interface.
On USB 3 this could be cut down to 47 minutes.
On 10GigE it might be as low as 15 minutes.
On 40GigE, Infiniband or whatever, in theory, it could be even faster. But that is only the network portion and assumes 100% efficiency with 100% available capacity.
-
@scottalanmiller said
No, does not need to be the same. Although Veeam Free will leave you without some of the things that you want. Unitrends or XenOrchestra will likely do a better job for you here when trying to do this for free.
Though no file level.
Always better to have an agent if you need that.
-
@PRPL said in Converting to a virtual environment:
Also, how long would be take to restore a 1TB VM ?
The REAL questions will be far less about your network but more about your backup media, your restore media (server storage) and backup utilities. How fast do each of them work. Putting in a 10GigE network is easy and relatively cheap if you don't need much switching (or any switching.) But getting disks that can maintain the data needed to send out a restore, and then having the disks on your server to ingest a restore of 1TB is where it gets complicated. Just because your network can get it there doesn't mean that the disks, the protocol or the software doing the transfer will be able to maintain it.
I don't know anything that will attach via USB that will be able to pull this off. You will need a more serious storage device to be able to handle it.
-
@BRRABill said in Converting to a virtual environment:
@scottalanmiller said
No, does not need to be the same. Although Veeam Free will leave you without some of the things that you want. Unitrends or XenOrchestra will likely do a better job for you here when trying to do this for free.
Though no file level.
Always better to have an agent if you need that.
Unitrends does file level. But not for free.
-
I wonder if that import/export bug is XS would affect restoring/importing a VM...
I'm not sure what mechanism XO uses for that on a straight restore.
-
Of major consideration in a restore like this is the write speed of the server array. RAID 10 is the fastest array type, for example, and still its write speed is half that of its read speed. So the array would have to be able to stream out 1TB in 45 minutes to be able to restore one in 90 minutes. And that's best case scenario.
-
SSDs will help, but even SSDs won't do 1TB in 90 minutes without some thoughtful design and planning.
-
hmm... We have around 600 - 700GB of data, on 1 server .. , and around 200 - 250GB on another ...
If you'll say that an External USB HDD, won't be upto the task to backup/restore the VM, then this idea is moot ..
-
@scottalanmiller said
I don't know anything that will attach via USB that will be able to pull this off. You will need a more serious storage device to be able to handle it.
It depends on what you are trying to accomplish.
For just protecting from a VM blowup, why not attach a USB as a SR? That would work, no? I know in the past you said no one attaches USB drives to servers, but not sure I believe that.
Of course that doesn't protect from a disaster with the machine itself.
-
@PRPL said in Converting to a virtual environment:
hmm... We have around 600 - 700GB of data, on 1 server .. , and around 200 - 250GB on another ...
If you'll say that an External USB HDD, won't be upto the task to backup/restore the VM, then this idea is moot ..
External HD is never a recommended backup system. Or almost never. There are lots of problems with that approach. Does it work? Normally. But it is fragile and very, very slow. It's not that having one work is impossible, just improbably. USB is not a serious connection technology and no one is going to build a truly fast system and then put USB on it, the two just don't go together. USB drives are for trivial data and not for infrastructure components. I know you are trying to make things work on a budget, and maybe you have no choice, but if possible you don't want to have this and you should not think of it as a serious backup system. It's crufty at best, fragile at worse.
External USB means you have to physically get to the machine, unplug from one and plug into the other just to start restoring. That alone is a major problem. What if you are ten minutes away from the office? Or in the bathroom? You don't have enough time for that, your restore window is not large enough.
I don't know any USB attached device that can push enough data for you to restore in time.
-
@PRPL said in Converting to a virtual environment:
hmm... We have around 600 - 700GB of data, on 1 server .. , and around 200 - 250GB on another ...
So which machine has the 1TB VM?
-
@BRRABill said in Converting to a virtual environment:
@scottalanmiller said
I don't know anything that will attach via USB that will be able to pull this off. You will need a more serious storage device to be able to handle it.
It depends on what you are trying to accomplish.
For just protecting from a VM blowup, why not attach a USB as a SR? That would work, no? I know in the past you said no one attaches USB drives to servers, but not sure I believe that.
Of course that doesn't protect from a disaster with the machine itself.
Backup storage can't just be generically attached. How would it be mounted as an SR? Even if the backups were storaged as VHDs (anyone know a product doing that), how would the host know how to handle the delta files? Backups storage is not just a mirror of production storage.
-
@BRRABill said in Converting to a virtual environment:
@scottalanmiller said
I don't know anything that will attach via USB that will be able to pull this off. You will need a more serious storage device to be able to handle it.
It depends on what you are trying to accomplish.
For just protecting from a VM blowup, why not attach a USB as a SR? That would work, no? I know in the past you said no one attaches USB drives to servers, but not sure I believe that.
Of course that doesn't protect from a disaster with the machine itself.
Sure people attached USB's to servers because they are bidding their time, hoping it doesn't fail, trying to accomplish something with as little as possible.
For a scenario like this that @PRPL is in he could* build his own backup server from parts he has lying around, he needs at most 4TB of space.
To build something new for this would be incredibly cheap (recommended no, likely not) but as an absolute stop gap before using a USB to backup; a cheap "whitebox" server with the storage needed would be vastly better.
-
One of the reasons that USB Drives don't work in this scenario is that you need two different backup systems, totally independent from each other, to handle the two servers. And then there is no clear means of restoring in the case of a server failure without hardware changes. And in the case of a breach, the backups are totally exposed (tightly coupled) at all times to the server. So if someone got access to the server, not only is your server at risk, but they will "own" all of your backups too. To the point that it is only marginally possible to even call this a backup, technically the USB drive is external, but it is so physically close and so much just a slow, internal drive that it's more a copy, less a backup.
-
@scottalanmiller said in Converting to a virtual environment:
One of the reasons that USB Drives don't work in this scenario is that you need two different backup systems, totally independent from each other, to handle the two servers. And then there is no clear means of restoring in the case of a server failure without hardware changes. And in the case of a breach, the backups are totally exposed (tightly coupled) at all times to the server. So if someone got access to the server, not only is your server at risk, but they will "own" all of your backups too. To the point that it is only marginally possible to even call this a backup, technically the USB drive is external, but it is so physically close and so much just a slow, internal drive that it's more a copy, less a backup.
In a smallish shop, the server you are backing up to is probably pretty close tot he actual server.
We're not talking offsite redundancy here.
You could throw Linux on a spare machine and accomplish what you are looking for pretty cheaply.
