Backup of ADABAS for OpenSystems using Veritas .... etc

Customer is a big Veritas user and wants to do on-line backups of the ADA/NAT environment on OS.

  1. Can we do this.
  2. Has anyone done it ?


Yes, I did!
I think there are 3 possiblilities:

  1. Do a ONLINE-backup of the ASSO- and DATA-Files on the filesystem (I guess that’s the way Veritas would do it):
    This method cannot be recommended. If you backup the ASSO/DATA-Files on the Filesystem, you’ll get an inconsistent Database if you make a restore. Another Disadvantage is, that you’ll backup all empty Adabas-Blocks as well.
  2. Do one Offline-Backup via ADABCK. The next Backups can be done using the PLOG-Option. That means:
  • force a new Plog
  • Backup the old Plog-File
  1. Do an ONLINE-backup using ADABCK:
    This is a consistent method to do a online Backup. But you can run into trouble in case of a ET_SYNC. Please see
    and the ADABAS-Documentation of ADABCK.

Possibility 1: Inconsistent database blocks can be avoided by using the ADAOPR EXT_BACKUP functionality.


Interesting Feature! The Documentation says:

The keyword PREPARE prepares the database for backup. During this phase, the following restrictions apply: 
- new transactions will be stalled 

So my question is: What is the advantage of ADAOPR EXT_BACKUP over ADABCK EXU_DUMP? If I understand the whole thing correctly, both ways are locking the Database for the users.

Modern storage systems allow creating a (logical) copy of data in a very short time. This means that you can get a consistent copy of your containers by doing the following:
adaopr ext_backup=prepare
Save the containers with the storage system functionality
adaopr ext_backup=continue

Note that ADABAS is blocked for updates between adaopr ext_backup=prepare and adaopr ext_backup=continue. Therefore it is not recommended using this feature for saving the database with a real physical copy operation.

On the other hand, ADABCK will lock the database only for a short time for update when the whole database has already been written to the backup file do do a final synchronization. If database blocks are updated while ADABCK is running, they are written to the backup file a second time if they have already been written to the backup file before.


I’m trying to use this features to clone ( using storage utility ) adabas ( v.6.x.x. more or less 300GB of DATA/ASSO/WORK CONTAINER ) on linux platform.
Sometimes adaopr db=xx ext_backup=prepare takes a long time to complete ( more then 1 houres ).
Can it depends on TT or TNAE parameters?
Can someone help me on this topic?

It is not clear to me if EXT_BACKUP=PREPARE is performing ET synchronization? If seems not because there is not ET_SYNC_WAIT parameter like for ADABCK. If ET synchronisation is performed this could be the reason for your 1 hour wait time (TT has to expire). But then new transactions can also not start in the meantime which can be a big problem.

If it is not performing ET synchronisation I don’t understand why the example in the manual is not including WORK in the external backup:

Perhaps Wolfgang can clarify this?

Yes, of course an ET synchronization is necessary. The idea of ADAOPR EXT_BACKUP is to create a consistent state of the containers on disk. Additionally to the ET synchronization also a buffer flush is necessary. For ADAOPR EXT_BACKUP no ET_SYNC_WAIT parameter is provided, but you can set TT to a smaller value before performing EXT_BACKUP, for example:
adaopr db=…tt=20 ext_backup=prepare
When you continue processing after saving the containers you should set TT back to its original value, for example:
adaopr db=… ext_backup=continue tt=3600

Thanks Wolfgang.

So it is very likely it is your TT value that takes your prepare long time to complete. It is just waiting for ET-synchronization.
I highly recommend you to lower TT before the prepare because new transactions cannot start while waiting for this synchronzstion. And set it back again afterwards.

The considerations is the same as running online adabck.


Found a chapter in documentation about this topic →

If all else fails, consult the documentation. :wink: