Back-Up

From Unofficial BOINC Wiki

[edit] General

This is a term that is used to define both a process and a result of that process. We take the data contents of a computer system that is important and then save it to various media to ensure that any mishap with the computer does not destroy both the computer and the data it contains. In a Project like any of the BOINC Powered Projects and the scientific research that they support there is data that most of us would be annoyed to lose. For example, how would you feel if all of those Cobblestones that you have gained over a couple years, just went "poof!". I doubt that you would like that. More importantly, the data collected by the project and saved in the Science Database would have to be recalculated if lost.

The data set that is created is usually stored on slower and less expensive media like magnetic tape, CD-ROM, DVD, etc. and moved to more secure storage in a place other than the building next door. Especially in California, an earthquake would take out the computer and all the back up data in one swell foop! So, we make a back up (sometimes called an "image") and send it elsewhere. This is one of the primary responsibilities of the System Administrators. Oh, and to be real sure, you also test the Back-Up image to make sure that a restore will work.

One of the system folks told us how he does the back-up at SETI@Home (Powered by BOINC):

"When I do a backup of the database I do it off a snapshot. I stop all the projects, the web site, basically anything that touches the database. Then I flush the database and halt it. At this point it is in a perfectly stable state as it was cleanly shut down."

"Then I snapshot the filesystem which contains all the data. This is completely outside of the realm of MySQL's control - it's strictly part of the OS and volume manager. Then I restart the database, the projects, etc."

"At this point, the snapshot is 0 bytes long, but every time a page of N bytes gets altered in the "live" database, the pre-altered N bytes gets added to the snapshot to preserve the original state when the snapshot was made."

"So while things like the data purge process is running and deleting huge chunks from the live database, the snapshot is busy just trying to maintain its original state by copying the unaltered database pages to itself. From the user perspective, the snapshot remains perfectly stable - but there's a lot of work going on under the hood to keep it this way."

"That's what I mean about copy-on-writes. Every write to the database results in a copy to the snapshot. Double the I/O, slowing everything down."

"There is no replica database server right now. If there was, then the backup would be completely painless. Instead of the above, I wouldn't have to stop the projects, web server, etc. at all. The replica database is simply a second instance of mysql running on another machine that, every time the master updates the database, it tells the replica to do the same exact thing."

"Yes, this is double the I/O but it is twice the machine, so that's not a problem. When it comes time for backup, I simply tell the replica to halt getting updates from the master. It'll be in a perfectly stable state while the master continues chugging along. I then do the backup on the halted replica (which is fast because there is no other I/O) or make a snapshot of it like the above (so we could turn it back on again)."

- Matt BOINC/SETI@home