Oracle Database Backup Techniques

Use the techniques listed below to make sure you don't forget critical steps during a weekly database backup.

Back up the primary database once a week. If you create, modify, or stop a database, add a new SQL Server message, add or stop connecting to a server, or add a recording device, make a manual backup.

Back up the msdb database once a day. It is generally very small, but important because it contains all of the SQL Server work, operations, and scheduling tasks.

It is only necessary to back up the model database when you modify it.

Use the SQL Server Agent to schedule your backup work.

If you have a ready-made resource in your production (production) environment, back up the production database to a local disk or a network server (with the same switch). Then, copy the backup file/device to the tape. In the case of many hardware failures (especially in a raid system), the disk is often intact (inact). If the backup file is on disk, the speed of recovery is much higher.

The backup development and test database should at least use the simple recovery model.

In addition to scheduled scheduled backups, back up the user database after an nonlogged batch operation (such as a batch copy), creating an index, or changing the recovery model.

If you are using the simple recovery model, remember to back up your database after the truncated (truncate) transaction.

Record your recovery steps in the document. At a minimum, you should probably record these steps and note the location of all the important files.

All of this information is saved in the transaction before the truncated record, that is, before all submitted (committed) transactions are emptied from the record. In the simple recovery model, records are truncated during a checkpoint period (when the SQL Server memory buffer is written to disk), it occurs automatically, but can also be performed manually. This is why the simple recovery model does not support Point-in-time (Point-in-time) restores. Under the full and bulk_logged recovery model, transactions are truncated when transactions are backed up, unless you explicitly point out that they are not truncated.

To back up transactions, use the BACKUP LOG command. The basic syntax is very similar to the backup command:

BACKUP LOG {database} to <backup device>

Here's how to back up the transaction to an example on a logical device named Logbackupdevice:

BACKUP TRANSACTION Northwind to Logbackupdevice

If you do not want to truncate the transaction, use the NO_TRUNCATE option as follows:

BACKUP TRANSACTION Northwind to Logbackupdevice with No_truncate

It's just basic knowledge.

Although I've just outlined the basics of database recovery in this article, you can still use these techniques to find the right direction. So, to avoid unnecessary panic (loss of data), you have to back up the main database every week and back up msdb daily.