There are some really great suggestions here, and I'm very thankful . . . but I don't feel confident about my skills as a programmer to implement a complex and advanced system like effective journalling and recovery. I mean, I probably could find a way to do it poorly, but I'm already pushing my novice skills as is. My focus is more on getting the game finished while having it useable and stable. I've seen how easy it is for a game project to fall into the void of never-getting-finished due to feature creep, and there's only one of me after all.
Now, SQL is something I am a little bit familiar with. Though I'm not too knowledgeable about performance for it, is that something I need to worry about? So far the load I'm planning on supporting is roughly up to 24 concurrent clients/players (hard limit at 64 due to select(), but the more the merrier), and some players can have the server take over for them while they're gone. Also, I'm expecting that there can be many small updates to game data as players plan their actions out.
So my current plan is this. I have two rough sets of data: data specific to a game instance (game data), and everything else (system data). I've already programmed in a good chunk of the system data, and it's all read/written as tab-separated text files. A lot of that data is simple, irregularly changed (ie password hashes), and if corrupted, easy for server operators to spot and fix by hand. Game data on the other hand, is much more transient, sizable, homogenous, and the context may not be as obvious (whereas "name=john_smith" has very obvious context in a client account file). Hence the dual focus on efficient saving, and where data corruption becomes a much bigger concern in diagnosing and fixing. So I may go with a database there, and save the data every turn. If I want to push it, I could copy the game data to new structures after every turn, and then in a separate thread write the old data to disk. But I don't know if writing to the disk will cause the entire process to block, it's also not a subject I'm terribly familiar with. For me, getting it done takes precedence over being fancy.
SQlite sounds like a good idea; I'm using a lot of relational data anyways. The game I'm developing is a turn-based strategy game with tiled maps, so there is a lot of data to be stored per player/map, and a game could last longer than the lifetime of the server process.
I tried it that way, but then I ran into the problem that I need to use class methods for one to communicate to the other. But I don't know how to set any variables using class methods, and I don't know where the instances (I assume the framework is creating them) are.