Before you begin
Use synthetic files in a new empty lab directory. The worked program requires Python 3 and its standard library. Do not use live exports or service credentials.
Working toward: Write a maintenance and recovery runbook with measurable success criteria and a verified data transfer.
Read each explanation, run the example in your own lab, and attempt the exercise before opening its answer. Published lessons are ready to study; unfinished roadmap topics remain planned.
Validation: Based on upstream documentation. Platform-specific labs require the learner’s matching environment and are not execution-tested here.
1. Define recovery goals
Recovery point objective describes tolerable data loss measured in time. Recovery time objective describes the target time to restore service. Backups, dependencies, people and procedures all affect whether those objectives are attainable.
What to expect
A one-page plan naming the service, its dependencies, acceptable loss, restore time target, backup locations, recovery owner and validation steps.
Your turn
If backups run nightly but acceptable loss is one hour, is the plan sufficient?
Show answer and reasoning
Not by itself. You need a mechanism and tested process capable of recovering a more recent point, such as appropriate transaction-log backups or another supported design.Watch for: Do not confuse backup frequency with proven recoverability or replication with independent protection.
Link to this lesson2. Validate an import before writing
CSV is text, not a database schema. Parse its structure, check required fields and unique identifiers, then stage validated rows before changing the destination. This fixture deliberately contains only two known contacts.
import csv, io
source = io.StringIO("id,name\n1,Ada\n2,Lin\n")
rows = list(csv.DictReader(source))
seen = set()
for row in rows:
if not row["id"] or not row["name"] or row["id"] in seen:
raise ValueError("Missing field or duplicate ID")
seen.add(row["id"])
print(f"Validated {len(rows)} rows")What to expect
Validated 2 rows. The program does not write to a database.
Your turn
Change the second ID to 1. What should happen before any destination update?
Show answer and reasoning
The validation raises ValueError. Reject or quarantine the batch and report the offending row; do not silently overwrite a different record.Watch for: CRM is a category of application, not a universal schema or vendor. Map fields, encoding and relationships explicitly for the actual system.
Link to this lesson3. A change needs an exit condition
A patch procedure should define its target versions, prerequisites, test fixture, observation window, expected service checks, and rollback decision. Rebooting successfully is only one check.
What to expect
A maintenance record with before/after versions, application check results, backup verification and a decision to accept or roll back.
Your turn
A host is patched but its application cannot connect to the database. Should the change be called complete?
Show answer and reasoning
No. Evaluate the documented service checks and dependency errors. Follow the tested rollback or repair plan and record the outcome.Watch for: Do not assume a VM checkpoint covers an external database, directory or storage dependency.
Link to this lessonPath to advanced
In-progress stages identify the lessons already published. All other listed topics remain planned. Each addition needs teaching, a reproducible lab, failure cases, and a checkpoint before the capstone.
Data operations
Staging imports, schemas, encoding, checksums, row reconciliation and access controls.
PLANNEDMaintenance
Patch inventories, vendor advisories, compatibility tests, change windows and rollback decisions.
PLANNEDRecovery capstone
Recover a service on a separate target, verify its data and document time and data-loss results.
PLANNED
References
Original AUWEN lessons, with upstream documentation for further study and version checks.
All learning paths and update notes →