4 ms·

I find my self saying this a lot lately Just because technology A can do action B, does not mean it's the most appropriate path to take

tdavis 17y ago
I know what you mean. Yeah, I could do this, or I could just rely on automated iSCSI snapshots to seamlessly and automatically backup the entire machine whenever I want.
- bretthoerner 17y ago
  Are those reliable for a database, though? I haven't done enough at such a low level to really understand how that would work. I mean, the database application layer typically promises to be atomic, sure. But at any given point in time are the bits on disk truly atomic? Does a database not sometimes take 2+ writes to fully change data? And does an iSCSI backup really copy the entire disk at a single point in time? I thought that was magic specific to something like ZFS. Because if it doesn't, couldn't you have a database backup that isn't really usable? I guess what I'm trying to say is that application level DB dumps exist for a reason - and I'm no expert so I'd love someone to explain how full disk backups work re: databases.
  - dcurtis 17y ago
    In general, you are supposed to lock the database for a couple seconds, take the snapshot, and then unlock it. This prevents that kind of data corruption.
  - tdavis 17y ago
    DB dumps exist for a reason Indeed they do, and that is the "faultless" way of creating a backup. Depending on your RDMS (and luck perhaps), the backups can be fine or they can be unusable. In my experience, MySQL databases backed up this way almost always end up being corrupted. On the other hand, I've had good success with PostgreSQL. Sure, occasionally the internal registry indices will be out of sync and will need to be recreated, but it has never been a big deal. Even still, I wasn't decrying DB-level backups since, obviously, they're far better (and sometimes necessary). But you can still start a cronjob to write the backup and let the snapshots take care of the rest. My point is, you already get heavy-duty compression and incremental algorithms and restoration, not to mention the ability to restore the complete system state in the event of a catastrophe.
rams 17y ago
Before I could complete saying "Just because you can doesn't ..." I read your comment. Voted up.

tdavis 17y ago

I know what you mean. Yeah, I could do this, or I could just rely on automated iSCSI snapshots to seamlessly and automatically backup the entire machine whenever I want.

bretthoerner 17y ago
Are those reliable for a database, though? I haven't done enough at such a low level to really understand how that would work. I mean, the database application layer typically promises to be atomic, sure. But at any given point in time are the bits on disk truly atomic? Does a database not sometimes take 2+ writes to fully change data? And does an iSCSI backup really copy the entire disk at a single point in time? I thought that was magic specific to something like ZFS. Because if it doesn't, couldn't you have a database backup that isn't really usable? I guess what I'm trying to say is that application level DB dumps exist for a reason - and I'm no expert so I'd love someone to explain how full disk backups work re: databases.
- dcurtis 17y ago
  In general, you are supposed to lock the database for a couple seconds, take the snapshot, and then unlock it. This prevents that kind of data corruption.
- tdavis 17y ago
  DB dumps exist for a reason Indeed they do, and that is the "faultless" way of creating a backup. Depending on your RDMS (and luck perhaps), the backups can be fine or they can be unusable. In my experience, MySQL databases backed up this way almost always end up being corrupted. On the other hand, I've had good success with PostgreSQL. Sure, occasionally the internal registry indices will be out of sync and will need to be recreated, but it has never been a big deal. Even still, I wasn't decrying DB-level backups since, obviously, they're far better (and sometimes necessary). But you can still start a cronjob to write the backup and let the snapshots take care of the rest. My point is, you already get heavy-duty compression and incremental algorithms and restoration, not to mention the ability to restore the complete system state in the event of a catastrophe.

rams 17y ago

Before I could complete saying "Just because you can doesn't ..." I read your comment. Voted up.