The database (even a RUNNING database) at any point in time can be thought of as:

- the datafiles are a "snapshot" as of a point in time
- the redo logs and archived redo let you move than snapshot forward to the point in time requested.

The reason I say even running is that when you make changes to a running database, we don't immediately flush those changes to the datafiles. They are always slightly out of date, but thats OK because we have the redo logs to keep things in sync.

Thus backup/restore is the logical extension of that.

If you do a full backup once per week, and you want to restore to any point in time during the week, you'll need the archivelogs for a week. If that is too much, you could do more frequent full backups or include some incremental backups during the week. The nice thing with RMAN is that you don't need to specify which backups to use on a restore - it will just use the best ones for the requested point in time.

I'd recommend the following as a simple starting point

- full backup monday
- backup archivelogs every day, set redundancy to 2 so you have 2 copies of every archive log (because if one gets corrupted this could be critical).
- use delete expired at the end of each backup to clear out archives you already have 2 copies of.

But don't forget, disk is super cheap (ie, the disk you would need for backups) - you can get terabytes very cheaply. I would always prefer to have too many backups then too little!