3 ms·

Does anybody use ZFS as replacement for a database backup/restore on a test environment? I'm not sure but it seems that it's possible to use ZFS snapshots in or

Does anybody use ZFS as replacement for a database backup/restore on a test environment? I'm not sure but it seems that it's possible to use ZFS snapshots in order to quickly restore previous database state. Note: it's just a question, I'm not advising to try that.

orf 9y ago
File system snapshots of databases are not necessarily consistent, and can not always be restored like that.
- floatboth 9y ago
  Atomic snapshots like ZFS's are always consistent for Postgres. I guess other databases with a similar write-ahead log can be snapshotted as well?
  - anarazel 9y ago
    > Atomic snapshots like ZFS's are always consistent for Postgres. As long as you make sure to only use one filesystem, i.e. you don't place pg_xlog or some tablespaces on a different filesystem. You can get very weird corruption in such cases :)
    - olavgg 9y ago
      With ZFS you can also do atomic snapshots of multiple filesystems. https://serverfault.com/questions/608223/is-zfs-snapshot-r-of-several-pools-atomic https://serverfault.com/questions/608223/is-zfs-snapshot-r-o...
  - jerry40 9y ago
    Interesting. I played with ZFS years ago on opensolaris, I don't remember there were atomic snapshots. I definitely need to dive into ZFS again.
- jerry40 9y ago
  But if we "stop" this database/schema, make ZFS snapshot (I suggest that the "partition" keeps only this database related files) it may work. It can be useful for testing purposes I guess.
deleted 9y ago
[deleted]
mioelnir 9y ago
Well, not in a test environment, but for production updates of some NoSQL stuff, sure. Snapshot the datasets, clone them over into a new rw-dataset, run the upgrade on the clone. Upgrade went wrong and corrupted your files? Destroy the clone and make a new one, then run it again (after fixing whatever caused the corruption obviously). Want to test the upgrade in your production environment beforehand? Well, make a clone a couple days early. And once all works out, a few days later you promote the clone and destroy the old datasets. Need a rollback? Well, just start the old application instance on the old datasets, nothing touched them. Doesn't work for all database types, especially if you have no possibility to replay new data into the rollback. But if your system allows it, it is really comfortable.
- jerry40 9y ago
  Thanks, very interesting.

orf 9y ago

File system snapshots of databases are not necessarily consistent, and can not always be restored like that.

floatboth 9y ago
Atomic snapshots like ZFS's are always consistent for Postgres. I guess other databases with a similar write-ahead log can be snapshotted as well?
- anarazel 9y ago
  > Atomic snapshots like ZFS's are always consistent for Postgres. As long as you make sure to only use one filesystem, i.e. you don't place pg_xlog or some tablespaces on a different filesystem. You can get very weird corruption in such cases :)
  - olavgg 9y ago
    With ZFS you can also do atomic snapshots of multiple filesystems. https://serverfault.com/questions/608223/is-zfs-snapshot-r-of-several-pools-atomic https://serverfault.com/questions/608223/is-zfs-snapshot-r-o...
- jerry40 9y ago
  Interesting. I played with ZFS years ago on opensolaris, I don't remember there were atomic snapshots. I definitely need to dive into ZFS again.
jerry40 9y ago
But if we "stop" this database/schema, make ZFS snapshot (I suggest that the "partition" keeps only this database related files) it may work. It can be useful for testing purposes I guess.

deleted 9y ago

[deleted]

mioelnir 9y ago

Well, not in a test environment, but for production updates of some NoSQL stuff, sure. Snapshot the datasets, clone them over into a new rw-dataset, run the upgrade on the clone. Upgrade went wrong and corrupted your files? Destroy the clone and make a new one, then run it again (after fixing whatever caused the corruption obviously). Want to test the upgrade in your production environment beforehand? Well, make a clone a couple days early. And once all works out, a few days later you promote the clone and destroy the old datasets. Need a rollback? Well, just start the old application instance on the old datasets, nothing touched them. Doesn't work for all database types, especially if you have no possibility to replay new data into the rollback. But if your system allows it, it is really comfortable.

jerry40 9y ago
Thanks, very interesting.