Simple about SAP basis: 2026

11/07/2026

S/4HANA System Refresh: A Step-by-Step Guide for Basis Teams

Refreshing an S/4HANA QA or dev system from Production is routine work, but the post-refresh list runs longer than it did on classic ECC ‚Äî embedded analytics, Fiori, and logical-system-sensitive configuration all need their own pass.

Before you start: the pre-refresh checklist

Freeze transports into the target system for the duration of the refresh.
Record every RFC destination and logical system name currently configured on the target ‚Äî you'll need to restore some of these after the DB copy overwrites them.
Export any client-specific configuration you don't want silently replaced by Production's values.
Confirm the backup/restore or snapshot window with the DBA/HANA team and the business calendar ‚Äî not just the technical window.

Two ways to move the data

HANA backup and restore: take a data backup from source, restore it to target. Straightforward, works across any infrastructure, but slower on large databases. Storage or array snapshot: a DBA/storage-team-driven copy at the disk layer, far faster for large systems, but it needs infrastructure support for snapshotting and cloning to already exist. Pick based on your downtime budget, not habit.

Core Basis steps

Stop SAP on the target and take a backup of the target first, in case anything requires a rollback.
Restore or snapshot the HANA database from source onto the target.
Run post-processing: BDLS to rename the logical system, SCC4 to correct client settings, SM59 to repoint RFC destinations away from production endpoints, and clear the number range buffer.
Reschedule or re-trigger background jobs lost in the refresh ‚Äî see our background job troubleshooting guide if any come back cancelled instead of simply missing.
Reapply the license key with SLICENSE ‚Äî a full database-level copy wipes the one the target had.
Reset <sid>adm and database user passwords to target-specific values. Never leave production credentials live in a lower system after a refresh.

S/4HANA-specific extras

Refresh the Fiori Launchpad and ICF service cache ‚Äî stale service registrations are a common cause of tiles failing to load right after a refresh.
Re-check client-dependent authorizations on embedded analytics CDS views; these don't always carry over cleanly from a BDLS rename.
Update the refreshed system's registration in Solution Manager / your landscape tool so monitoring and EWA reports point at the right SID again.

The most expensive mistake to get wrong

Outbound interfaces firing against production endpoints because RFC destinations weren't repointed before the system came back up. This is the single costliest post-refresh mistake ‚Äî a test message, an EDI document, or a payment run can leave the lower system and land in a live production process. Repoint and lock down outbound RFCs and interfaces before starting SAP on the target, not after.

FAQ

What is BDLS used for after an SAP system refresh?

BDLS renames the logical system in a client after a refresh or copy, so documents and interfaces reference the correct (target) system instead of still pointing at the source system's identity.

Why does my SAP system try to send data to production after a refresh?

Because RFC destinations and interfaces copied over from production still point at live production endpoints. Repoint SM59 destinations and disable or redirect outbound interfaces before starting the system on the target.

Do I need a new license key after an SAP system copy?

Yes ‚Äî a full database-level copy or restore invalidates the target's existing license, since the license is tied to the system's hardware key. Reapply it through SLICENSE after the copy.

SAP HANA Backup and Recovery: A Practical Guide for Basis Admins

HANA runs in-memory, but durability still depends entirely on backup discipline ‚Äî the persistence layer and the log area need to be backed up on purpose, on a schedule, the same as any other database.

The two backups HANA always needs

A data backup is a full copy of the persistence layer at a point in time. Log backups run continuously in the background and are what makes point-in-time recovery possible between data backups. Skip log backups and you can only ever restore to the last data backup, losing everything after it.

File-based vs Backint

File-based backups write straight to a filesystem path ‚Äî simplest to set up, fine for small or dev systems. Backint is the integration interface most production landscapes actually use, letting a third-party backup tool (Commvault, NetBackup, and similar) manage HANA backups the same way it manages everything else in the landscape, with retention and offsite copy handled centrally.

Triggering a manual data backup

Through HANA Cockpit's Backup tile, or directly in SQL:

BACKUP DATA USING FILE ('backup_name')

Checking backup health

Don't assume backups succeeded just because nothing paged you. Query the catalog directly:

SELECT * FROM M_BACKUP_CATALOG ORDER BY SYS_START_TIME DESC;
SELECT * FROM M_BACKUP_CATALOG_FILES WHERE BACKUP_ID = '<id>';

Look specifically for gaps in log backups, not just failed data backups ‚Äî a silent gap there is what turns a routine restore into a bigger data-loss event than anyone expected.

Point-in-time recovery, at a glance

Recovery replays the most recent data backup and then every log backup up to the timestamp you choose. In practice: stop the system (or the affected tenant in a multi-tenant setup), open the recovery wizard in HANA Cockpit or Studio, choose "recover to point in time," and select the timestamp. HANA handles replaying the chain of backups itself ‚Äî you don't manually restore files.

Common pitfalls

Log area filling up. Usually caused by log backups being disabled or the backup destination becoming unreachable ‚Äî this is a classic cause of a HANA system hanging with no obvious error.
Stale backup catalog pointers. After a storage migration, the catalog can still point at the old backup destination path. Verify it explicitly rather than assuming the migration updated everything.
Forgetting SYSTEMDB in multi-tenant (MDC) systems. SYSTEMDB holds the catalog and tenant metadata ‚Äî back it up alongside the tenant databases, not instead of them.

FAQ

How often should SAP HANA log backups run?

Continuously, in the background, by default ‚Äî they're what makes point-in-time recovery possible. The setting to check is the backup destination and retention, not a schedule, since HANA writes log backups as segments fill rather than on a fixed timer.

What happens if the HANA log area fills up?

The database can hang or stop accepting writes, because it can't log new transactions. This is most often caused by log backups failing silently ‚Äî an unreachable backup destination or Backint agent issue ‚Äî rather than by transaction volume alone.

Can I restore an SAP HANA database to a specific point in time?

Yes ‚Äî HANA's recovery process replays the most recent data backup plus the chain of log backups up to the timestamp you choose, through HANA Cockpit, Studio, or the command-line recovery tools.

STMS Transport Troubleshooting: Fixing Failed and Stuck SAP Transports

A stuck transport blocks everything scheduled behind it in the same queue, so it's worth treating as the first thing you fix in a morning, not the last. Start with the return code ‚Äî it tells you which of a small number of actual problems you have.

Read the return code before you touch anything

RC0 ‚Äî success, nothing to do.
RC4 ‚Äî warnings only; usually fine, but worth a glance at the log if the transport affects something critical.
RC8 ‚Äî errors, most often objects that imported but didn't activate. Go to SE80 and check the objects in the transport.
RC12 ‚Äî a severe error during import; read the full log, don't just retry blind.
RC18 ‚Äî the transport was aborted or not found; check that the data and cofile actually made it to the target's transport directory.

Stuck "in process" and the queue won't move

First check whether the background job that actually runs imports (RDDIMPDP) is still active on the target ‚Äî if it died, nothing moves no matter how many times you re-trigger from STMS. Then check the transport buffer:

tp showbuffer <SID>

If the buffer looks out of sync with what STMS shows, reset it the safe way rather than touching files under /usr/sap/trans by hand:

tp cleanbuffer <SID>

Authorization failures during import

These get missed because people check the developer's dialog-user authorizations and stop there. The import itself runs under the RFC background user or <sid>adm, which needs S_TRANSPRT and S_CTS_ADMI ‚Äî check that user's roles, not the developer's.

Objects import but won't activate

Almost always a sequencing problem: a data element imported before its domain, or a structure before a table it depends on. Run a mass activation in SE80 first ‚Äî it often resolves the dependency order on its own. If it doesn't, re-export the missing prerequisite object into a follow-up transport.

Two OS-level commands worth knowing by heart

# Connection test between systems
R3trans -d

# Check the import queue for a target SID from the command line
tp connect R3<DBSID> <SID>

Don't confuse transport routes with SAP Router

STMS transport routes control which systems a change object can move between; SAP Router is a completely separate network-level relay that lets SAP support and remote systems reach your landscape through a firewall. The two get mixed up constantly because both involve the word "routing." If you're troubleshooting connectivity rather than a change failing to import, you're looking for the latter ‚Äî see SAP Router Installation step by step.

FAQ

What does RC8 mean in a SAP transport log?

RC8 means the import completed with errors ‚Äî most commonly that one or more objects imported into the target system but failed to activate. Check SE80 for the specific objects named in the transport log.

Why is my transport stuck in the import queue?

Usually one of two things: the RDDIMPDP background job that actually processes imports has stopped running on the target, or the transport buffer is out of sync with what STMS is showing. Check the job first, then the buffer with tp showbuffer.

How do I check the SAP transport buffer from the command line?

Run tp showbuffer <SID> as the system's administrator user. To reset a buffer that's out of sync, use tp cleanbuffer <SID> rather than editing files under /usr/sap/trans directly.

SAP Background Job Troubleshooting: Why Jobs Get Cancelled and How to Fix Them

Background jobs are invisible right up until one fails during month-end close and three people are suddenly watching you troubleshoot it live. SM37 is where you start, but it rarely tells the whole story on its own.

Start in SM37, not the ticket

Pull up the job by name and date range and check its status first: Scheduled and Released mean it hasn't run yet; Ready means it's waiting for a free background work process; Active means it's running now; Cancelled is what you're here for. Open the job log before anything else ‚Äî it almost always names the failing step.

The five most common cancellation causes

ABAP runtime error. The job log references a short dump ‚Äî go straight to ST22 and read it; the dump text usually names the exact statement that failed.
No free background work process. The job sat in Ready for a long stretch before cancelling. Check SM50/SM66 for work process saturation and RZ04 for how many background processes the current operation mode allocates.
The job's user got locked or its password changed mid-run. A dialog user's password expiring under a scheduled job is one of the most common silent killers. Use a dedicated background/service user with a non-expiring password for anything scheduled.
A missing or changed variant. Someone deleted or renamed the variant the job step points to. Check the Step tab in SM37 against what actually exists in SA38.
Authorization failure. The job runs under a user that's missing a role needed by that specific step. SU53 right after the failure, or an ST01 authorization trace if SU53 doesn't catch it, will show the missing object.

Reading the return code correctly

Don't conflate three different things that all get called "the RC": the job's overall status in SM37, the ABAP step's own return code, and ‚Äî for jobs that call external programs like tp ‚Äî that program's separate return code scale. Check the job log's return code first; it tells you which of the three you're actually looking at.

Cross-check the system log

SM21, filtered to the job's time window, catches what ABAP never reports to the job log at all ‚Äî a full archive filesystem, a database connection drop, an OS-level resource limit. If ST22 shows nothing but the job still cancelled, this is the next place to look.

Preventing the next one

Spread jobs across job classes A/B/C instead of scheduling everything for the top of the hour.
Use a dedicated, non-expiring background user for scheduled jobs ‚Äî never a named dialog user's ID.
Monitor proactively with RZ20/CCMS or an external monitoring tool, rather than waiting for the business to report a missed job.
For jobs that depend on each other, use event-based scheduling instead of fixed time gaps ‚Äî a slow upstream job otherwise cancels the downstream one for "missing data" that was simply still being written.

FAQ

What does job status "Cancelled" mean in SM37?

It means the job started but didn't complete ‚Äî it stopped partway through a step rather than finishing normally. The job log for that run names the step and, usually, the reason.

How do I find out why a background job failed?

Open the job log in SM37 first. If it points to a short dump, check ST22. If it shows nothing specific, check SM21 for the same time window for an OS or database-level cause ABAP wouldn't have reported.

Can a locked user cause a background job to fail?

Yes ‚Äî if the user the job runs under gets locked, has its password expire, or loses a required role mid-schedule, the job cancels with an authorization or logon error even though nothing about the job itself changed.

Top 20 Linux Commands Every SAP Basis Administrator Should Know

Most SAP systems built today run on Linux ‚Äî SUSE or Red Hat under S/4HANA ‚Äî which means Basis work increasingly starts at the OS prompt, not inside SAPGUI. These twenty commands cover the five things you'll reach for daily: watching the system, controlling the SAP instance, reading logs, moving files, and checking connectivity.

System and process monitoring

ps -ef | grep <sid>adm ‚Äî confirm which SAP work processes are actually running under the instance owner.
top ‚Äî live CPU and memory by process; the first stop when a system "feels slow."
free -h ‚Äî memory and swap in human-readable units; check swap usage before blaming the application.
df -h ‚Äî filesystem usage by mount point; the classic cause of a stuck archive or spool is a full filesystem.
du -sh * ‚Äî size up a directory's contents when df says a filesystem is full but you don't know what's eating it.

Controlling the SAP instance from the OS

su - <sid>adm ‚Äî switch to the SAP administrator user with its full environment loaded.
sapcontrol -nr <NN> -function GetProcessList ‚Äî the OS-level equivalent of SM51, useful when SAPGUI itself won't connect.
startsap / stopsap ‚Äî start or stop the instance cleanly instead of killing processes by hand.

Reading logs without opening SAPGUI

tail -f dev_w0 ‚Äî follow a work process trace live while reproducing an issue.
grep -i error dev_w* ‚Äî scan every work process trace for errors in one pass.
less ‚Äî page through a large trace or log file without loading the whole thing into an editor.
zgrep / zcat ‚Äî search or view rotated, gzip-compressed logs without decompressing them first.

Finding and moving files

Full walkthroughs of these two live on this blog already ‚Äî command reference here, details in the linked posts.

find /usr/sap/<SID> -name "*.trc" -mtime +30 ‚Äî locate trace files older than 30 days before a cleanup. See The Linux find Command.
tar --list --verbose --file archive.tar.gz ‚Äî inspect an archive's contents before extracting it. See The TAR command | Bash Basics.
scp file.tar.gz user@host:/path/ ‚Äî copy a file securely between SAP hosts.

Networking and connectivity checks

ping <host> ‚Äî confirm basic reachability before chasing an RFC error.
telnet <host> <port> (or nc -zv <host> <port>) ‚Äî check whether a specific port is actually open; this catches firewall issues telnet-to-host alone misses.
ss -tulpn ‚Äî list listening ports and the process holding each one; the modern replacement for netstat.

Editors, permissions, and the rest

vi / vim ‚Äî unavoidable for editing config on a server with no GUI. See VI Shortcuts & Commands For Newbies and How to Exit From VIM (VI)? if :wq isn't yet muscle memory.
sudo <command> ‚Äî run a single command with elevated rights without logging in as root. See Linux Commands For Beginners: SUDO.
chmod / chown ‚Äî fix file permission and ownership issues, a common cause of a work process failing to write its own trace file.
crontab -l ‚Äî check what's scheduled on the OS level, separate from SAP's own job scheduler.

Quick reference

Command	Use it for
ps -ef \| grep sidadm	Confirm SAP work processes are running
top / free -h	CPU, memory, swap at a glance
df -h / du -sh	Filesystem space and what's using it
sapcontrol -function GetProcessList	SM51 from the OS prompt
tail -f / grep / less / zgrep	Reading and searching logs
find / tar / scp	Locating, archiving, and moving files
ping / nc -zv / ss -tulpn	Connectivity and port checks
vi / sudo / chmod / chown	Editing config and fixing permissions

FAQ

Do SAP Basis administrators need to know Linux?

Yes ‚Äî most current SAP installations, especially S/4HANA, run on SUSE or Red Hat Enterprise Linux. SAPGUI covers application-level administration, but instance control, log review, and OS-level troubleshooting all happen at the Linux command line.

What command switches to the SAP administrator user?

su - <sid>adm switches to the SAP system's administrator account with its environment (paths, SAP-specific variables) loaded, which plain su <sid>adm without the dash does not do.

How do I check if SAP work processes are running from the OS?

Run ps -ef | grep <sid>adm to see the raw OS processes, or sapcontrol -nr <NN> -function GetProcessList for the same view SM51 shows inside SAPGUI.