[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Backup solution
Artur Linhart - Linux communication wrote: This is.... optimistic. The saved state of RAM in such a process is potentially "dirty" with cached data not yet written to disc. And atomic operations, such as database operations, are potentially in mid-process because the write to disc is not complete and the database is still locked at the time of the save. And systems like Linux tend to keep as much possible of the paged material in RAM, rather than necessarily writing to disk. And some filesystems, such as ReiserFS, are *particularly* horrid about not completing file-system operations and then attempting to recover from them.Hello, I§ve thought about it and i think the good compromise seems to be for me 1. start "xm save" to archieve the current and consistent state of the memory 2. during the "xm save" command is running , the domain is paused, I can create the snapshot volume during this time (in script could be waited till the saved memory snapshot file will be created on the disk, if I understand it correctly, at this moment the domain must be already paused, so now the snapshot can be created 3. after the save is executed, the xm restore can be done again (or the command "xm save" can be started with the option -c to leave the domain running after the memory snapshot will be created, but this can be dangerous in the case the "xm save" would take too less time to create the snapshot volume during this time) With all that added together, I'd consider this reasonable if crunched for downtime, but not reasonable for high reliability of sensitive databases such as Oracle, db4, MySQL, or that mess of twisty little undocumented formats all different called an Outlook userfile. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |