[falcolas]

So, it appears to just copy tables around within the database. I wouldn't want to use this on a DB over a few MB in size. Sure, restores are "fast" (a table rename), but copies are not so much.

I can't imagine this would be kind to a production database (lots of cleanup from copied & deleted tables), and would consume a lot more space than a gripped logical backup of the tables in question.

[obsession]

I have regularly used this with database that's nearing 1000 megabytes. I don't particularly mind slow snapshotting because my workflow is more about restoring database back to baseline than taking copies.

Please don't use this for production. It is not stable enough and you only end up with lost data.

[falcolas]

Why not use a binary backup method? Faster to backup and restore.

[martin_]

Agreed. I've been successfully using mylvmbackup on 10gb+ databases for a few years now.

http://www.lenzg.net/mylvmbackup/

[fud]

We use our own lvm solution at work, works great, we do something like pgsnap to swap to the snapshot or pgsnap master to work on the master. I'll check this out.

[obsession]

Interesting, I'll have to take a look.

[sciurus]

For those curious, on PostgreSQL it executes

    CREATE DATABASE "snapshot" WITH TEMPLATE "source";

and on MySQL it loops creates the new database and loops over all the tables running

    INSERT INTO snapshot.table SELECT * FROM source.table;

https://github.com/fastmonkeys/stellar/blob/master/stellar/o...