[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |