On Mon, Nov 12, 2007 at 01:00:04PM -0500, Dan Langille wrote: > On 12 Nov 2007 at 9:48, Jason Martin wrote: > > > use, best practice is to dump the data to an ASCII file, then backup > > > the file. > > I'd suggest that it would be better to follow whatever procedure > > is proscribed by the DBMS documentation :> This would be a very > > poor way to back up Oracle, for example. > > Why is this a very poor way to back up Oracle?
It is not really a backup of a database as far as Oracle is concerned, it is a backup of an export. Oracle is all about maintaining a coherent stream of 'redo' such that you can effectively roll the database forward/back to any point in time. The only recovery you can make from an export is to put the database back as it was at the time of the export. A proper backup allows you to recover the database up to the moment the last 'commit' returned successfully against it, or any point between the datafile backup and the most recent commit. Not that export doesn't have its uses, but those uses are not for backing up a production database.* Oracle will tell you the best way to back up Oracle is to use RMAN and have your media manager (bacula in this case) back up the resulting files from the flash recovery area. Another option (the 'user-managed' option as they put it) is to put the database in hot-backup mode and have bacula back up the 'live' files. Putting Oracle in hot-backup mode puts additional information in the redo logs such that it can recover from the files having changed mid-backup. Hot-backups are an integral feature to Oracle so there is no risk in doing it this way. That said, always test your backups. RMAN is helpful since it makes sure you have all the necessary files, while user-managed requires additional work to make sure you have everything. http://6URL.com/1F5R (this is a q/a site from an Oracle VP) As far as bacula is concerned, you would likely have a before-script that either invokes RMAN to generate a backupset, or puts the db in hot-backup-mode, the job backs up the appropriate files, and (if in hot-backup-mode) an after-job command that turns off hot-backup-mode. These methods preserve the database continuity, and combined with archive-logs allows you to recover to the point-in-time immediately before a failure. Other RDBMSs may have similiar setups. Exporting to a dump file may be the correct procedure for MySQL, but I just wanted to point out that special consideration needs to be taken for DBs in general as they each have their own rules on the proper backup methodology. Otherwise you are in for a rude surprise when you go to restore. Now, if you were referring to RMAN-generated files as the 'ascii files' mentioned above then we were talking about the same thing, but I assumed you were referring to exp/expdp/some-custom-tool generated files in this case as it is a common misunderstanding. * Not that a paranoid DBA can't do it on an occasional basis, but they should know the limitations of what they have and how it is unlike a proper backup) -Jason Martin Oracle 8i/9i/10g OCP -- This message is PGP/MIME signed.
pgpLdoMaxVdWm.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
