PDA

View Full Version : Backup of xen VM



lpphiggp
04-Sep-2014, 18:57
Probably a dumb question, but ..

I want to get a backup of our VM's, that is, the .raw file on the xen host.

Note that the VMs' user data is all stored on NSS volumes, which are mounted from a SAN, not part of the VM itself and already backed up through our backup solution, so all I'm interested in here is the OS, basically. Especially since these are OES servers tied into our Tree. They should be relatively static.

I know that to clone a VM, the VM must be downed first. Then the process only takes about 5 to 10 minutes or so. However, it is unlikely I'm going to be able to down our servers for even that long without protests.
Is there any reason I couldn't install my backup client on the host, and just backup the .raw files while the VMs are running?

ab
04-Sep-2014, 20:53
On 09/04/2014 12:04 PM, lpphiggp wrote:
>
> I know that to clone a VM, the VM must be downed first. Then the
> process only takes about 5 to 10 minutes or so. However, it is unlikely
> I'm going to be able to down our servers for even that long without
> protests.
> Is there any reason I couldn't install my backup client on the host, and
> just backup the .raw files while the VMs are running?

Yes, because you'll likely corrupt things unless you can do something to
prevent writing to the disk during that time. Unfortunately you'd only
notice that corruption upon a restore, when it's too late.

Could you create another instance, use clustering for your NSS resource,
and then backup one node at a time failing services back and forth? Since
you have NSS these are OES boxes and you can use Novell Cluster Services
(NCS) for most services (sans eDirectory) which would have a replica on
each server anyway.

Other options may be using some kind of filesystem snapshotting
technology. I am not sure what that'd look like from the host, or if your
host's filesystem has that as an option, but maybe it'd work. I prefer
the cluster option because it gives you another benefit (failover) at the
same time.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

jmozdzen
05-Sep-2014, 10:40
Hi lpphiggp and ab,

On 09/04/2014 12:04 PM, lpphiggp wrote:
>
> I know that to clone a VM, the VM must be downed first. Then the
> process only takes about 5 to 10 minutes or so. However, it is unlikely
> I'm going to be able to down our servers for even that long without
> protests.
> Is there any reason I couldn't install my backup client on the host, and
> just backup the .raw files while the VMs are running?

Yes, because you'll likely corrupt things unless you can do something to
prevent writing to the disk during that time.
[...]
Other options may be using some kind of filesystem snapshotting
technology. I am not sure what that'd look like from the host, or if your
host's filesystem has that as an option, but maybe it'd work.

I would advise against this option, as you'd be snapshotting the host file system, not the guest file system.

You could think of this as instantly copying the physical disk of a machine - while there still may be tons of unwritten updates in the OS caches :(

How about backing up from within the virtual machine? Treat it like you'd treat any physical machine...

Regards,
Jens

lpphiggp
05-Sep-2014, 14:59
Hi lpphiggp and ab,

I would advise against this option, as you'd be snapshotting the host file system, not the guest file system.

You could think of this as instantly copying the physical disk of a machine - while there still may be tons of unwritten updates in the OS caches :(
How about backing up from within the virtual machine? Treat it like you'd treat any physical machine...

Regards,
Jens

Hi Jens,
I thought of that, but we don't have bare metal recovery type capabilities (requires a separate licen$e), so I'd still have to create an (OES) server from scratch so that I'd have something to restore to, plus it would have to go back in the Tree, so I'm not sure that would really work.

lpphiggp
05-Sep-2014, 15:15
On 09/04/2014 12:04 PM, lpphiggp wrote:[color=blue]


Yes, because you'll likely corrupt things unless you can do something to
prevent writing to the disk during that time. Unfortunately you'd only
notice that corruption upon a restore, when it's too late.

Could you create another instance, use clustering for your NSS resource,
and then backup one node at a time failing services back and forth? Since
you have NSS these are OES boxes and you can use Novell Cluster Services
(NCS) for most services (sans eDirectory) which would have a replica on
each server anyway.

Other options may be using some kind of filesystem snapshotting
technology. I am not sure what that'd look like from the host, or if your
host's filesystem has that as an option, but maybe it'd work. I prefer
the cluster option because it gives you another benefit (failover) at the
same time.


Thanks ab. I was afraid that'd be the answer.
We could look at clustering in the future, since the data is on a SAN, but, that'd be something new for us (well, me) and doesn't sound like a quick fix, so to speak, especially with all the other projects looming over me currently.
The host is SLES11sp3, running ext3.

I guess I'll try to make a case to justify downing the VMs just long enough to create a clone, start the VM back up ASAP, then I can backup or move the clone at my leisure.
I 'll run that through my supervisors, and change control; after all, it's a worthy cause.

KBOYLE
05-Sep-2014, 17:15
lpphiggp wrote:

> I guess I'll try to make a case to justify downing the VMs just long
> enough to create a clone, start the VM back up ASAP, then I can backup
> or move the clone at my leisure.

There are other options, depending on how you have configured your
storage. If you happened to have your DomU's storage on a Dom0 logical
volume (LVM), you could take a snapshot of the LV in a matter of
seconds then do your backup from the snapshot at your leisure.

If this is something you plan to do periodically, you may want to
consider it.

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

lpphiggp
05-Sep-2014, 18:38
lpphiggp wrote:

> I guess I'll try to make a case to justify downing the VMs just long
> enough to create a clone, start the VM back up ASAP, then I can backup
> or move the clone at my leisure.

There are other options, depending on how you have configured your
storage. If you happened to have your DomU's storage on a Dom0 logical
volume (LVM), you could take a snapshot of the LV in a matter of
seconds then do your backup from the snapshot at your leisure.

If this is something you plan to do periodically, you may want to
consider it.

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

Thanks, that'd be a nice alternative, but we just made a vanilla linux native ext3 partition for sda1 and 2.
We've never really delved into logical volume mgmt on linux.

jmozdzen
08-Sep-2014, 12:17
Hi lpphiggp,

Hi Jens,
I thought of that, but we don't have bare metal recovery type capabilities (requires a separate licen$e), so I'd still have to create an (OES) server from scratch so that I'd have something to restore to, plus it would have to go back in the Tree, so I'm not sure that would really work.

I anticipated such a response, once I had sent my reply :D Might creating a single (offline) image backup and supplementing that with (online) incremental backups from within the guest be a solution?

Regards,
Jens

lpphiggp
08-Sep-2014, 17:17
Hi lpphiggp,


I anticipated such a response, once I had sent my reply :D Might creating a single (offline) image backup and supplementing that with (online) incremental backups from within the guest be a solution?

Regards,
Jens

That sounds like a plan.

I thought all I should need for these two VMs was just a one time snapshot sort of thing, as all the user data and email are on separate physical NSS partitions, via our SAN. The servers run no other services like DHCP or DNS.
But then I remembered, they have R/W replicas. Whoops. A simple snap won't do.