What we snapshot
Each landscape gets a full daily snapshot of the database and the application filesystem, held for a rolling window. Dedicated landscapes can keep a longer retention on request.
- Database snapshot including redo logs
- Application server filesystem and profiles
- Transport directory so your changes survive a restore
How we test them
On a rotating schedule we restore a snapshot into an isolated environment, start the instance and run a short smoke test: log in, open a transaction that reads and writes, and check the update queue is clean.
If a restore fails, that is a real incident for us even though no customer noticed — the point is to find it before you need it.
What a restore looks like for you
Message us with the date and time you want to go back to. We confirm the nearest available snapshot, take a fresh copy of the current state first — in case you change your mind — and restore. Shared landscapes are restored per environment so other tenants are unaffected.
Key takeaways
- Ask any provider when they last completed a test restore
- Transports and profiles matter as much as the database
- We copy the current state before restoring over it