Snapshot Vs Backup
The difference between a snapshot and a backup: A snapshot is, think
about it as a Polaroid picture. You’re out, and you’re having fun with
your friends, and somebody snaps a Polaroid or an Instagram or whatever
the kids are using nowadays. It’s just that. It’s an instant point in
time.
This can be appropriate for certain types of data and it can be inappropriate for other types of data. The reason why is because the snapshot, it generally happens again at the storage level, so it doesn’t have that intelligence, maybe that a true backup software or backup product has where it lives inside the operating system. Maybe it can communicate with your database server or your exchange server.
If you have something that’s very memory-intensive … Let’s take, for example, a SQL server, and it’s very transactional, you’re running a lot of database transactions very frequently, unless you get into some really, really specifics on storage array snapshots, you could end up in a state that’s called “crash inconsistency”. If your server would’ve come down, and you were to boot it back up, that data that your database had in memory might not have been cleanly written to disk so the consistency of your data in your database with a snapshot might not be valid.
With a traditional backup product, again, living inside the operating system, having knowledge of either the exchange server or the Oracle server or the SQL server, it can actually talk to those applications, make sure that all of that data that’s residing in memory be written to disk. That way, you can be sure that your server, if you have to restore it, is in a crash consistent state and you can be assured that your data is available.
This can be appropriate for certain types of data and it can be inappropriate for other types of data. The reason why is because the snapshot, it generally happens again at the storage level, so it doesn’t have that intelligence, maybe that a true backup software or backup product has where it lives inside the operating system. Maybe it can communicate with your database server or your exchange server.
If you have something that’s very memory-intensive … Let’s take, for example, a SQL server, and it’s very transactional, you’re running a lot of database transactions very frequently, unless you get into some really, really specifics on storage array snapshots, you could end up in a state that’s called “crash inconsistency”. If your server would’ve come down, and you were to boot it back up, that data that your database had in memory might not have been cleanly written to disk so the consistency of your data in your database with a snapshot might not be valid.
With a traditional backup product, again, living inside the operating system, having knowledge of either the exchange server or the Oracle server or the SQL server, it can actually talk to those applications, make sure that all of that data that’s residing in memory be written to disk. That way, you can be sure that your server, if you have to restore it, is in a crash consistent state and you can be assured that your data is available.
Comments