[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Re: FW: Xen Backups



Thank you so much for your help. 
I think the first option would be the best bet for us.  
Since I can not guarantee that there would not be any file changes
during the backup period, I would probably stop (or pause...I will have
to look into that option) the guests and work from there. We are running
production systems on the VM's but, we are not a 24 hour shop. For
disaster preparedness, I could probably schedule some downtime after
hours, every so often to take snapshots.

To make sure I understand, when you take a snapshot, it is the VM as it
looks now.  If the world went sideways, I could bring up a new SAN and a
new server, import the snapshot and be back up and running?

The more I look at this option, I see that it is a great disaster backup
but would not replace 'normal' backups.  We would still do 'normal'
disk-to-disk-to-tape backups to restore individual files.  The snapshots
would be for use in cases where we had to bring the entire VM back
online.

I am also looking into some networking issues.  Since we are just
getting started, those will be my priority however, once we are up and
running, I will revisit backups in more detail and will probably have
more questions at that time.

Thank you again for your help.  
 
 
James Alspach
Systems Analyst II
Shasta County Office of Education

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of joost@xxxxxxxxxxxxxxx
> Sent: Tuesday, June 03, 2008 1:29 AM
> To: Xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Re: FW: Xen Backups
> 
> > Wow...nice! This sounds like it would work great for guests that
have a
> > healthy command line (*NIX) but can you do the same thing on a
Windows
> > guest?
> 
> I'm not sure, as my server doesn't have HVM support.
> For a MS Windows guest, I would probably do either of the following 2:
> 1a) Stop the guest
> 1b) Create snapshots
> 1c) start the guest
> 1d) Create backups
> 1e) Remove snapshots
> 
> or
> 
> 2a) pause(suspend) the guest (is this possible with HVM?)
> 2b) create snapshots
> 2c) copy the pause-file
> 2d) resume the guest
> 2e) create backups (Ensure to keep the pause-file with it)
> 2f) remove snapshots
> 
> > I can see connecting to a windows server and then stopping some of
the
> > services but I am not sure how to mount or unmount a file system in
> > windows.
> 
> You don't need to actually mount/unmount filesystems as long as you
can
> ensure there will be no changes made to the filesystem during snapshot
> creation.
> 
> > Also, forgive my ignorance but, if you had a problem could you just
> > reinstall the snapshot and restart it?
> 
> What do you mean with reinstalling the snapshot?
> If the backup-process fails at any stage, I can resolve it simply by
> rebooting the virtual machine. The backups themselves are the actual
> filesystems, eg. I can restore this and my system is back.
> 
> > Is your script available somewhere or would you mind sharing it?
> 
> The script is not yet available somewhere as it's heavily dependent on
my
> installation and is not yet fit for distribution.
> 
> I am planning on documenting it properly this week and will be happy
to
> make it available.
> 
> > PS How about SAN based snapshots (on equipment other than the
Netstor)?
> > Is this something that people expect Xensource to support in the
future?
> 
> I have no experience with these, but I would guess that a similar
script
> would work.
> 
> --
> Joost
> 
> >>
> >> On Sunday 01 June 2008 15:33:32 Christian Tramnitz wrote:
> >> > I guess most people would like to avoid the necessary downtime.
> >> > On the other hand, when doing live-snapshots (i.e. LVM snapshot
> > target),
> >> > live-data may be corrupt (open file handles, databases)...
> >>
> >> I actually run a script on the host that does the following:
> >> All activities on the guest are done using SSH and shared key
> >> authentication
> >>
> >> 1) Stop the service(s) on the guest
> >> 2) Unmount the filesystem(s) on the guest to be backed up
> >> 3) detach the filesystems (xm block-detach <domain> <hd??/sd??>)
> >> 4) create snapshots
> >> 5) reattach the filesystems (xm block-attach <domain> <device>
> > <hd??/sd??>
> >> w)
> >> 6) remount the filesystems on the guest
> >> 7) Restart the service(s) on the guest
> >>
> >> I can then backup the filesystems using the snapshots and remove
the
> >> snapshots
> >> when the backups are finished.
> >> Using this, the total 'downtime' is around 40 seconds (on my
system)
> > to:
> >> - stop and start 3 services
> >> - backup OpenLDAP and PostgreSQL
> >> - unmount / mount 6 filesystems
> >> - detach / attach 6 filesystems
> >> - create 6 snapshots
> >>
> >> The script I use also has error-handling implemented in case any
> > action
> >> fails.
> >> This will prevent, for example, a detach-attempt to take place on
> > still
> >> mounted filesystems.
> >>
> >> HTH,
> >>
> >> Joost Roeleveld
> >>
> >> >
> >> > Best regards,
> >> >     Christian
> >> >
> >> > James Alspach wrote:
> >> > > How do most people backup their VM's?  I understand that the
> > suggested
> >> > > method right now is to install your backup client just as you
> > would if
> >> > > you were backing up a physical server.  It just feels like you
> > should
> >> be
> >> > > able to snapshot the entire VM instead of worrying about just
the
> >> data.
> >> > >
> >> > > For instance, how difficult it would be to script taking a VM
> > offline,
> >> > > exporting it and then bringing it back online.  To me this
sounds
> > like
> >> a
> >> > > good way to backup your VM's  (as long as you can stand them
being
> >> > > offline for some amount of time while they export).  If you
could
> > back
> >> > > up this way recovering from a disaster should be fairly
painless.
> > Just
> >> > > reinstall Xensource, hook it back up to the SAN and import the
> >> > > VM's...done.  What am I missing? Is it the size of the VM's
that
> > keeps
> >> > > this from being viable?
> >> > >
> >> > >
> >> > >
> >> > > Thanks for your help;
> >> > >
> >> > > James
> >> >
> >> > _______________________________________________
> >> > Xen-users mailing list
> >> > Xen-users@xxxxxxxxxxxxxxxxxxx
> >> > http://lists.xensource.com/xen-users
> >>
> >>
> >>
> >> _______________________________________________
> >> Xen-users mailing list
> >> Xen-users@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-users
> >
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> >
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.