아카이브 모드로 전환 하시면 됩니다. 

특정테이블 특정시간으로 복구 가능합니다. 

백업의 경우 동원가능한 다양한 관련 기능으로 구성되는 것이 바람직해 보입니다.

1. 플래쉬백의 유효범위 증대를 위한 언두테이블스페이스 업사이징(볼륨 가용 범위 내), UNDO_RETENTION 조정

- 과거에 비하여 디스크 단가가 이미 많이 저렴해진 듯 합니다.

- 유사 시의 효용성과, 데이터 복구 소요시간 면에서도 유용성/용이성이 매우 높다고 보여집니다.

2. 주요 데이터의 경우 테이블 단위로 주기적 익스포트(expdp/exp)

 - 현실성면에서 객체 크기에 영향을 받습니다.

 - 중요한 참조 정보의 경우, 테이블단위 익스포트에 용이한 크기일 경우가 많습니다.

3. 백업 테이블 유지

 - 서비스 이용도가 낮은 시간대를 이용한 일자 별 백업 테이블 유지

 - 보존 정책에 의하여, 일정 기간 유지후 폐기

4. 오라클 감사(Audit, Audit Vault) 기능 활용

- 주요 스키마, 객체, 행위에 대한 감사 기능 활성화(인스턴스 재기동 수반) 및 구성

5. 치명적인 장애에 대응하기 위한 핫(BEGIN END) 백업

 - 아카이브로그 파일을 이용하여 time base로 원하는 시점의 데이터로 복원 가능

 - 주요한 테이블스페이스만으로 구성 가능

 - 요구되는 복원 시점을 미리 판단할 수 없으므로, 아카이브 파일을 미리 적용하지 않고 파일시스템에 유지만 함

 - BEGIN시점으로 부터 시간이 오래 경과될수록 아카이브파일 적용에 대한 부담이 늘어나 복구소요시간이 길어지는 딜레마 존재

 - 복수(2개 이상)의 클론 인스턴스 구성 정책을 세워서 딜레마 보완

6. 스토어드 PL/SQL 객체에 대한 백업

 - DBA_SOURCE에 주기적 백업 (백업일자를 선행컬럼으로 하는 백업테이블을 생성)

7. 더 나아가 DR(disaster recovery) 시스템 구성

.

.

가장 빠르고 쉽게 적용할 수 있으면서 가성비 좋은 방법으로 1번을 꼽고 싶습니다.

DBA입장에서 롤백세크먼트는 필요시 바로 꺼내 쓸 수 있는 현금과 같다고 보여집니다.