OpenVZ Forum: Support » Checkpoint/Backup of a container

Home » General » Support » Checkpoint/Backup of a container

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Checkpoint/Backup of a container [message #34479]

Fri, 09 January 2009 13:56

gurtaj
Messages: 12
Registered: September 2008
Location: London, Ontario, Canada

Junior Member

Hello, all. I've been reading and playing with OpenVZ, and have spent some time thinking about how to backup a container.

To backup a container I need to do a dump of it and also to make a copy of the filesystem at the time of the dump, right? If the filesystem is modified between the moment of the dump and the moment when the container is restored, errors might occur, so I need to keep a copy of the filesystem at the moment. Am I right?

Now, from what I understood from Andrey Mirkin ( http://forum.openvz.org/index.php?t=msg&goto=13558&& amp;srch=checkpoint#msg_13558), the best way to backup a container is to execute:

vzctl chkpnt VEID --suspend
vzctl chkpnt VEID --dump
vzctl chkpnt VEID --resume

There's no way to backup a container without suspending it, right?

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34485 is a reply to message #34479]

Sun, 11 January 2009 17:08

Martin Maurer
Messages: 13
Registered: January 2008

Junior Member

gurtaj wrote on Fri, 09 January 2009 08:56

Hello, all. I've been reading and playing with OpenVZ, and have spent some time thinking about how to backup a container.

To backup a container I need to do a dump of it and also to make a copy of the filesystem at the time of the dump, right? If the filesystem is modified between the moment of the dump and the moment when the container is restored, errors might occur, so I need to keep a copy of the filesystem at the moment. Am I right?

Now, from what I understood from Andrey Mirkin ( http://forum.openvz.org/index.php?t=msg&goto=13558&& amp; amp;srch=checkpoint#msg_13558), the best way to backup a container is to execute:

vzctl chkpnt VEID --suspend
vzctl chkpnt VEID --dump
vzctl chkpnt VEID --resume

There's no way to backup a container without suspending it, right?

see vzdump
http://wiki.openvz.org/Vzdump

or just use Proxmox VE - including a GUI for vzdump.

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34487 is a reply to message #34485]

Sun, 11 January 2009 22:32

januszzz
Messages: 50
Registered: January 2007
Location: Opole, Poland

Member

Hmm, vzdump is cool, but what it reaqlly does? AFAIK it does rsync, then freezez VE, rsyncs again, then resume.

So what if a database is running inside VE and it writes to the disk almost continously during the backup operation ? can I be sure I'll launch the databse in consistent state after restore of VE?

I guess I cannot. Still the database should be stopped or archived using its own tool. And this is difference to VMware snapshot, Virtualbox or KVM snapshot.

Am I right?

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34489 is a reply to message #34487]

Mon, 12 January 2009 07:09

Martin Maurer
Messages: 13
Registered: January 2008

Junior Member

januszzz wrote on Sun, 11 January 2009 17:32

Hmm, vzdump is cool, but what it reaqlly does? AFAIK it does rsync, then freezez VE, rsyncs again, then resume.

vzdump has different modes. if you work with LVM snapshots you have no freeze and no downtime.

1. Stop the VE during backup (very long downtime)
2. Use rsync and suspend/resume (minimal downtime)
3. Use LVM2 (no downtime, online)

januszzz wrote on Sun, 11 January 2009 17:32

So what if a database is running inside VE and it writes to the disk almost continously during the backup operation ? can I be sure I'll launch the databse in consistent state after restore of VE?

I guess I cannot. Still the database should be stopped or archived using its own tool. And this is difference to VMware snapshot, Virtualbox or KVM snapshot.

Am I right?

if you cannot life with a snapshot you need a backup software which is aware of the applications running. E.g. if you backup a microsoft active directory the backup software has to tell the microsoft server that there is a backup otherwise you can never restore.

most backup software vendors sells separate backup agents for this.

On Linux, doing backups with snapshots is working 99,9 % - thats my experience.

br, martin

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34491 is a reply to message #34489]

Mon, 12 January 2009 12:04

januszzz
Messages: 50
Registered: January 2007
Location: Opole, Poland

Member

Well, snapshots cannot be perceived as 100% reliable, as system memory writes immediately to disk when the VE unfreezes. If the system is not working hardly or content is static, then the snapshot is ok enough.

But if you run mysql or other database or any other system where data is particulary sensitive, you NEVER should rely on snapshot as it reverts to state of disk and NOT to the state of memory. Here the only way is to use application backup AND combine it with VE snapshot together.

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34492 is a reply to message #34491]

Mon, 12 January 2009 13:39

Martin Maurer
Messages: 13
Registered: January 2008

Junior Member

januszzz wrote on Mon, 12 January 2009 07:04

the system never freezes if you do snapshots with LVM (vzdump). I never had issues with Postgres, Mysql etc.

januszzz wrote on Mon, 12 January 2009 07:04

But if you run mysql or other database or any other system where data is particulary sensitive, you NEVER should rely on snapshot as it reverts to state of disk and NOT to the state of memory. Here the only way is to use application backup AND combine it with VE snapshot together.

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34493 is a reply to message #34492]

Mon, 12 January 2009 14:46

januszzz
Messages: 50
Registered: January 2007
Location: Opole, Poland

Member

I do not expect that kind of answers - "in 99.9% works, I've never had problems with...". I've never had problems too, I avoid problems, but...

...but I would really enjoy to hear that although it usually works, there is little-but-there-is a chance to crash your database.

I got mysql in VE and there are very long transactions. It's easy to simulate the crash here; although transactions should be done properly by the database, it doesn't see it was frozen, so the transaction could be broken in the middle.

I don't know how it works, but this is how I get it.

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34560 is a reply to message #34489]

Sat, 17 January 2009 23:21

gurtaj
Messages: 12
Registered: September 2008
Location: London, Ontario, Canada

Junior Member

Martin Maurer wrote on Mon, 12 January 2009 02:09

januszzz wrote on Sun, 11 January 2009 17:32

Hmm, vzdump is cool, but what it reaqlly does? AFAIK it does rsync, then freezez VE, rsyncs again, then resume.

The third option seems interesting, but requires a different setup than the one I'm using right now. However, I'll take note of it for the future.

Thanks.

Report message to a moderator

Re: Checkpoint/Backup of a container [message #34565 is a reply to message #34479]

Sun, 18 January 2009 19:24

n00b_admin
Messages: 77
Registered: July 2006
Location: Romania

Member

I used to manage a MySQL too.

I was using vzdump with the rsync option but i needed to hack it for the VE of the db server.

The steps used to consistently backup the MySQL server were:

1. With the VE running, do first rsync.
2. Stop the MySQL service inside VE.
3. Do final rsync.

This is what i used without any problems. the downtime for the SQL server was small, it took longer to bring down the service than to make the final rsync Smile

Hope this helps.

Report message to a moderator

Previous Topic:	Weird file access / rights problem
Next Topic:	"cpus" config option and "--set cpus" issue

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Mon Nov 18 17:55:41 GMT 2024

Total time taken to generate the page: 0.02916 seconds