On Mon, Mar 07, 2016 at 07:55:33PM +0100, Guus Snijders wrote: > Op 7 mrt. 2016 14:02 schreef "Jack Coats" <j...@coats.org>: > > > > If that is the case, it should be great for 'i just erased my last weeks > work' problem, but disaster recovery would be a issue (or for any non-flat > file recovery, like databases that are backed up 'live' rather than exports > being backed up). > > I guess I'm missing the point here, but in the case of the 'live' > databases; how is that different? > > Isn't that restore case always the same? Or should I think more along the > lines of feeding the data back to the dbms and let the software itself care > about storing the data?
You have three options: 1. Stop the database, thus freezing transactions to the filesystem. Make your backup. Restart the database. Pros: consistent, works, as fast as any consistent backup can be. Cons: stops your database. 2. Tell your database to dump a consistent copy of itself out to a backup directory. Make the backup. Pros: consistent, works, no database downtime. Cons: on restore of a database, you MUST drop your existing files and restore from the clean dump. Failure to do this will cause your database to be inconsistent. Not all databases support this feature. (But Postgres, MySQL/MariaDB, and Oracle do.) 3. Don't stop the database, just make the backup. Pros: fast, uncomplicated. Cons: almost guarantees an inconsistent database and many problems down the line. Don't do this. Any backup system should be scriptable to do (1), by stopping the database before invoking it and restarting afterwards, or (2) by making the backup contingent on a database dump. -dsr- _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
