| Backup Strategy for Multiple VEs [message #23772] |
Mon, 26 November 2007 12:57  |
seanfulton
Messages: 105
Registered: May 2007
|
Senior Member |
|
|
I'm wondering if any of you have thoughts on doing daily backups of individual VEs.
Currently we have a set of scripts that will back up an entire machine to a backup server, but I'm not sure if replicating that into each VE will work, because each backup would only "see" what the VE sees.
I'm hesitant to use full-system backups on the HN because that would take *hours* to recover a single file for a single VE.
Any ideas? What are other people using? We will have about 150 VEs across several machines all backing up to a network backup server.
sean
|
|
|
|
|
|
|
|
|
|
| Re: Backup Strategy for Multiple VEs [message #23788 is a reply to message #23786] |
Mon, 26 November 2007 23:15  |
ugob
Messages: 271
Registered: March 2007
|
Senior Member |
|
|
Without re-installing, that is not easy. I woudn't know how to do... Well I think you only need your /vz partition to be under LVM, so you could migrate all your VE to another server, reconfigure your server so that it uses LVM, then bring back your VE on the original server.
Not a simple task.
Have you tried the --suspend? It does create a downtime of a few seconds generally, but you may not want to try that if you have clients that may scream at you...
If not you can use vzdump without any method, but you may end up with an inconsistant backup.
Please read the manual before asking questions:
http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
Please have a look at the wiki before asking questions:
http://wiki.openvz.org/Main_Page
|
|
|
|
|
|
| Re: Backup Strategy for Multiple VEs [message #23849 is a reply to message #23789] |
Wed, 28 November 2007 05:06 |
ugob
Messages: 271
Registered: March 2007
|
Senior Member |
|
|
| seanfulton wrote on Mon, 26 November 2007 18:24 |
I can re-install the partition that /vz is on with lvm. If that will work, then I don't have to do a complete re-install. I tried suspend and it was great--only down for a minute or so. I just like to be thorough.
Ok, don't forget to leave at least 512 MB free in the logical volume, it is needed for snapshot (go for 1024, just to be sure)
|
| seanfulton wrote on Mon, 26 November 2007 18:24 |
In answer to your other question about what the VE sees, I was talking about when you are inside the VE and run tar or find, you will only see what is in the environment, not the configs or anything else, so that's why I wanted to avoid that.
But vzdump seems very nice. Thank you for your help.
|
My pleasure. I'm pretty sure vzdump will fit your needs. I'm trying to make it work with sshfs, but in vain for now.
Please read the manual before asking questions:
http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
Please have a look at the wiki before asking questions:
http://wiki.openvz.org/Main_Page
|
|
|
|
| Re: Backup Strategy for Multiple VEs [message #27020 is a reply to message #23849] |
Thu, 07 February 2008 00:24 |
seanfulton
Messages: 105
Registered: May 2007
|
Senior Member |
|
|
Question for you:
I was able to use sshfs and vzdump to make backups, and it was fantastic.
Then I started getting corruption on the ext3 filesystem on one of my SATA drives (not over the sshfs connection, on another drive on the *client* machine).
The drive was purchased in may, two of them were actually, they are both running on different machines with different controllers and both are showing the same corruption issues.
The only things that appear to be in common are the host machine (SuperMicro servers), both are using the OpenVZ kernel (47 and 53), and both are using sshfs mounts. The problem only cropped up in the last couple of weeks (the 47 kernel has been around longer than that), so that's why I suspect something new, aka sshfs.
I did some research on ext3 errors in the 2.6.18 kernels and found various spurious issues with the kernel, but one comment someone made was that user-space filesystem drivers could lead to memory corruption that would cause ext3 errors. I'm thinking if it were the 2.6.18 kernel itself, there would be tons of reports on this forum.
Then I remembered your post and was wondering: did you get sshfs working? If so, any issues with the drives on your machine?
It's possible it could be an issue with the controllers, which while both different, are both cheap, SATA150 controllers hooked to SATA300 drives. If I can't find another solution, I'm going to swap the controllers out.
I just thought perhaps you may have run across something like this.
Anything?
sean
|
|
|
|
| Re: Backup Strategy for Multiple VEs [message #27206 is a reply to message #27020] |
Tue, 12 February 2008 05:28 |
swindmill
Messages: 57
Registered: April 2007
|
Member |
|
|
I have my VEs mounted on an ext3 filesystem which lies on top of LVM and I create an LVM snapshot nightly via a script.
I then mount the LVM snapshot readonly and rsync to a remote system.
This way I am only transferring the files that have changed since the last backup and the VE experiences no downtime whatsoever, while the backup is in a consistent state because of the LVM snapshot.
If you wish to keep multiple days worth of backups present, using tar+gzip or something like dar on the server that is receiving the files would be suitable.
Just food for thought, feel free to reply if you want/need more detail on my backup implementation.
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
