Skip to Content
Product Information

HANA Fallback Snapshot – HANA 2.0 SP 03


This blog provide you an information on fallback snapshot, a new feature that has been introduced in HANA from HDB 2.0 SP 03 version.


From HANA 2.0 SP 03, there is a new feature called “Fallback Snapshot” which allows you to quickly and easily return back to a previous database state. You can create a fallback snapshot for a tenant database. It allows you to revert to a particular database state. If you no longer need the fallback snapshot, you can delete it. It can be used in below scenarios –

  1. Reset of Tenant Database used for Training
  2. Reset system back to previous state after performing import of Transport Requests to understand the sequence or performing testing for new region roll out.
  3. Reset system back to previous state if anything goes wrong while applying add-on/patch via SAINT

IMPORTANT NOTE: Below point needs to be kept in mind before using Fallback Snapshot:

  • Fallback snapshots can only be created for tenant databases.
  • Configuration changes are not included.
  • You can only create one fallback snapshot per tenant database. If you need to create a new fallback snapshot, delete the existing one first.
  • A service cannot be added or removed if a fallback snapshot already exists.
  • A fallback snapshot cannot be created if the tenant database is the primary database in a system replication scenario.
  • A fallback snapshot does not replace a database backup.
  • A fallback snapshot is not included in a database backup.

Always try to follow latest update guide while performing fallback snapshot, chances are this blog might not be updated regularly with any additional functionality in latest HANA release.


The database user with which you connect to the SAP HANA database has the privilege DATABASE ADMIN.


Open Manage Databases in the SAP HANA cockpit by drilling down from Overall Tenant Statuses in the system Overview for the system database.

As you can see, currently there are “No snapshot” for tenant database SL2. But before creating fallback snapshot, we will check the screen where we will be making changes after fallback snapshot.

In SAP Application (tcode – SU01), currently you can see that the last name is “Padia11”

Now we will be creating snapshot and make the changes in above screen.

Select the tenant for which you want to create snapshot, click on triple dot icon and select “Create Fallback Snapshot”

The moment you take fallback snapshot, it will perform a savepoint (16845) where your data will get persistent till the time when you took fallback snapshot

As you can see in Cockpit screen and indexserver log, we have the same time stamp for the fallback snapshot and savepoint.


After this all the changes that will be made in the system won’t get persistent in database. It will be part of redo log in the form of log segments and your /hana/log will continue to grow. So, you should make sure that you have sufficient free space in /hana/log to accommodate all changes after snapshot creation.

Fallback snapshot is not a replacement of backup, so you should make sure that you reset/delete fallback snapshot once you are done with your activity otherwise your /hana/log will keep on growing and your data won’t get persistent in /hana/data

As you might wonder that if my data does not get persistent after fallback snapshot what happen in case my system gets restarted?

Your system won’t be impacted as during start of system it will read the data till the last savepoint from /hana/data and after that all redo logs from /hana/log and bring up the system in up-to-date state.

Information of fallback snapshot can be found in M_SNAPSHOTS table.

After creating snapshot, we have changed the last name from “Padia11” to “Padia”

Now we will “Reset to Fallback Snapshot”

On resetting snapshot, your system get restarted (for obvious reason)

It will restart your system and perform recovery till last savepoint 16845. Once the recovery is done, it will perform another savepoint.

In SAP System, you will find that the last name has again changed back to “Padia11”

After resetting fallback snapshot, you have to delete it as it still remains even after resetting it.

Once you delete the snapshot, you have to reclaim log.

As you are aware, from HANA 2.0 cockpit needs to be installed separately but in case if you don’t have cockpit installed you can use below SQL command and also it can used for automation.

-- create
-- reset to snapshot
-- delete


SAP HANA Administration with SAP HANA Cockpit – Create a Fallback Snapshot

SAP HANA 2.0 SPS 03 What’s New: System Administration – by the SAP HANA Academy

ALTER DATABASE Statement (Tenant Database Management)




You must be Logged on to comment or reply to a post.
  • Nice Blog Dennis.

    Just a query. In case after making a fallback snapshot, whatever the changes functional/development team will do and at later point they say they want those changes as permanent and don't want to do rework. How will data become persistent again or redo of work is must?

    • Hello Ankit,

      If development team wants to make those changes permanent, then you can delete the snapshot instead of resetting it. On deletion of snapshot, it will perform a savepoint and make all that changes persistent.


    Hi Dennis,


    Thanks for the blog.


    I am interested in "Important Note".

    After this all the changes that will be made in the system won’t get persistent in database. It will be part of redo log in the form of log segments and your /hana/log will continue to grow. So, you should make sure that you have sufficient free space in /hana/log to accommodate all changes after snapshot creation.

    I have been searching for similar description in the HANA Administration Guide as well as the HANA Tenant Databases Operation Guide but I do not get one.

    Can you let me know where did you find them ?

    Thank you.




    • Hello Chiwo,

      It's an observation after I have performed fall back snapshot. I'm not sure whether it is mentioned in any guide.



  • Hi,

    a snapshot does not prevent writing to the persistency, it keeps all pages, existing at that moment.

    Further change operations to the pages write them to a different places.

    This means that the data area will grow more compared to not having snapshots.

    Kind Regards