Data Archiving 
We recommend that you regularly archive application data from completed business processes of your SAP applications. This level of archiving is distinct from backing up the underlying DBMS. Therefore, separate high availability considerations apply. Since archiving uses substantial system resources, be sure to plan it carefully with high availability in mind so as to minimize downtime and – from a performance perspective – system load.
SAP Data Archiving is based on the Archive Development Kit (ADK), which provides all functions necessary to archive SAP application data, and to access archived data. The archiving process has the following phases:
The write program copies the data objects from the database and writes them to archive files in the file system.
After reading the archived data in the archive files to verify the successful completion of the first phase, the delete program deletes the corresponding data from the database.
In archiving object-specific Customizing you can specify that the delete phase runs after the storage phase. This option increases the security of your data by guaranteeing that data is not deleted from the database until the archive files have been properly stored.
The archive files can then be transferred to a storage system for long-term storage.
By removing data that is no longer required in day-to-day business from the database, SAP Data Archiving reduces the volume of data in the database. Less data means less system downtime, as the time required for the following administrative tasks is reduced significantly:
Software upgrades
Database reorganization
Data backups
Data recovery
The technological foundation of data archiving is located in the SAP NetWeaver Application Server and is available in two different variations:
ADK-based archiving
ADK-based archiving is used only by ABAP applications that employ ABAP archiving objects in their data archiving projects
XML-based archiving
XML-based archiving is employed for XML archiving objects that are used by ABAP applications with XML interfaces, and for archiving sets used by Java applications
From a high availability point of view, the following recommendations apply for data archiving:
Recommendation
Do not make backups of the database content before running an archiving session
A backup (possibly requiring downtime) is not necessary before archiving, because an archiving session can be restarted without data loss if it has been unexpectedly interrupted.
Recommendation
Perform database reorganization only when necessary.
Archiving is often followed by database reorganization to reclaim the disk space freed by archiving. Since reorganization requires system downtime, consider carefully whether this is really necessary. For example, if a business application generates 100,000 business documents a week and they are archived on a weekly basis, nothing is gained by reorganizing after each archiving session, because the released disk space is reused every week. However, it is advisable to perform a database reorganization if the database index tables are highly fragmented.
Recommendation
Run archiving whilst working online.
Usually, archiving sessions can be run in parallel to online sessions. It is normally not necessary to cause downtime by closing online sessions to archive data.
Recommendation
Do not use the write program to delete data from the database.
ADK uses independent programs for writing the data to the archive and deleting the data from the database. If you modify the write program, do not include “delete” steps. It is best to execute these in the separate delete program to avoid data loss.