IBM i (AS/400) Disaster Recovery Runbook Template
When an IBM i system fails, the people who know how to restore it are often the same people under the most pressure. A written runbook replaces memory with steps, owners and target times.
Fill in
IBM i (AS/400) Disaster Recovery Runbook Template
Disaster Recovery Runbook: PRODIBMI
Company: Acme Precision Ltd Version: 1.2 Date: 2026-10-20 Plan owner: IBM i administrator
Objectives and Scope
Recovery time objective: 8 hours Recovery point objective: 24 hours, or last journal receiver if journaling is active Recovery target: Secondary partition at the second data center Backup method: Virtual tape to remote storage
Critical applications: JD Edwards World financials, distribution and manufacturing; EDI gateway; warehouse labeling.
Recovery Sequence
| Step | Action | Owner | Target time | Done |
|---|---|---|---|---|
| 1 | Declare disaster and notify the crisis team | |||
| 2 | Prepare the recovery system and confirm hardware and licenses | |||
| 3 | Restore the operating system and licensed programs | |||
| 4 | Restore user profiles and configuration | |||
| 5 | Restore application libraries and data | |||
| 6 | Apply journal changes if journaling is used | |||
| 7 | Validate data with the business owners | |||
| 8 | Start subsystems, network and interfaces | |||
| 9 | Open for users and communicate status |
Validation Checks
After restore, confirm record counts for key files, check the latest posted transaction date, run a sample order and a sample journal entry, and confirm interfaces reconnect. The business owner must sign that data is acceptable before general release.
Contacts
| Role | Name | Phone | Backup contact |
|---|---|---|---|
| Plan owner | |||
| Hardware vendor | |||
| Software vendor | |||
| Business owner | |||
| Network provider |
Test History
| Date | Type of test | Result | Time to recover | Actions |
|---|---|---|---|---|
Approvals
A starting point, not a complete plan. Adjust steps to your hardware, backup software, licensing and hosting arrangement. A plan that has never been tested should be treated as unproven.
Optional recovery readiness review
We can review your runbook against how your backups and licenses are actually set up.
Optional. The tool and every export work without this. No spam.
How to use the template
Fill in the objectives first. The recovery time objective is how long the business can live without the system, and the recovery point objective is how much data it can afford to lose. Name the recovery target and the backup method. Then complete the sequence table with real owners and target times, add contacts and print the document. Store one copy outside the production site, because a runbook on the failed system is no use.
- Agree RTO and RPO with business owners, not only IT
- Keep an offline copy of the runbook
- Include license key and serial number references
- Review after every system or backup change
The restore order
The sequence follows the usual IBM i recovery logic: operating system and licensed programs first, then user profiles and configuration, then application libraries and data, then journaled changes if you use journaling, then validation. Restoring in the wrong order can leave objects owned by profiles that do not exist yet or authorities that are missing. Your backup software documents the exact commands and your own order should match what your backups contain.
Testing and reading results
The test history table is the proof that the plan works. Record the type of test, such as a tabletop review, a partial restore or a full recovery on another system, and the actual time to recover. Compare the time with your RTO. If a test takes longer, either improve the process or revisit the objective with the business. Do not hide the gap.
Common mistakes
Common failures include backups that complete but cannot be read, license keys that do not match the recovery system, missing documentation for network settings and unclear authority to declare a disaster. Another frequent problem is assuming the recovery partition has enough capacity for the full workload. Check disk, memory and licensing in advance, and test restores regularly.
Frequently Asked Questions
How often should I test an IBM i recovery?
At least once a year for a full test, with smaller restore tests more often. Test again after major changes such as an operating system upgrade, a hardware move or a change in backup software.
What is the difference between RTO and RPO?
RTO is the maximum acceptable downtime. RPO is the maximum acceptable data loss measured in time. A 24 hour RPO means restoring from last night's backup is acceptable; a one minute RPO needs replication or journaling.
Do I need a hot standby system?
Only if your RTO and RPO require it. Many manufacturers accept several hours of downtime. The cost of replication should be compared with the cost of an outage using your own numbers.
Who should approve the runbook?
The plan owner, IT leadership and the business continuity lead at minimum, and the business owners for the objectives. Keep signed copies and review at least yearly.
Netray can help you build read-only checks that confirm each backup run is complete and restorable before you need it.
Related Tools
ERP Cutover and Go-Live Plan Template for IBM i Migrations
Fill-in cutover plan for migrating from an IBM i ERP: freeze window, final data load, validation, go or no-go criteria and rollback.
ERP OperationsIBM i Disk Growth and Capacity Forecast Calculator
Forecast how many months until IBM i auxiliary storage reaches your threshold, using current use, capacity and monthly growth.
ERP OperationsIBM i Batch Job Schedule Documentation Worksheet
Editable run book of scheduled jobs with timing, dependency, owner, runtime and restart notes plus a total nightly batch window.
ERP OperationsJD Edwards World and IBM i Change Request Form Template
Fill-in change request form for program, PTF, system value or data changes with backout plan and approval lines, exported as a clean document.
More ERP Operations tools
See all- IBM i Disk Capacity Runway Calculator
- ERP License Audit Risk Assessment
- ERP Support Cost Benchmark Calculator
- IT Ticket Backlog Cost Calculator
- ERP Database Growth Forecaster
- ERP Performance Health Check
- Legacy Report Modernization Calculator
- ERP Security Posture Checklist
- ERP Disaster Recovery Readiness Assessment