Home labs & practical projects

Recover a full filesystem without losing useful data

A project to do with your own tools, with guidance on what to create and capture.

Local lab Suggested time: 2–3 hoursYour own authorised environment

What you could create

A test Linux service cannot write because its dedicated filesystem is full. The operator must identify usage and recover capacity safely.

Example evidence format

Project evidence map (example)

Filesystem incident recordScope and inputs

Capacity recovery and monitoring procedureDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Filesystem incident record	Show the inputs, scope and decisions behind this record. The diagnosis identifies the constrained resource rather than deleting files at random.
Capacity recovery and monitoring procedure	Include the evidence supporting your conclusion. The recovery preserves the test data designated as required.

What you'll need

Local lab

Use a disposable VM with a small separate test volume. Fill it with harmless generated files, keeping the operating-system filesystem unaffected.

Project record

Keep the working files for filesystem incident record and record assumptions as you go.

Current reference material

Use the linked provider resources to verify the features, access terms and version relevant to your project.

Access & cost

Uses your own computer. Confirm hardware capacity, software licences and download terms before setup.

Use disposable VMs, containers or a simulator. Keep the lab separate from your everyday machine and work network.

Suggested milestones

1
Plan and investigate
Distinguish block usage, inode exhaustion and open deleted files where relevant.
2
Develop your approach
Choose a cleanup or capacity correction with a recorded data-retention decision.
3
Verify and explain
Restore service writes and define a monitoring threshold.

Evidence worth keeping

Keep clear, organised evidence of your design and any testing you carry out.

1
Filesystem incident record
Show the inputs, scope and decisions behind this record. The diagnosis identifies the constrained resource rather than deleting files at random.
2
Capacity recovery and monitoring procedure
Include the evidence supporting your conclusion. The recovery preserves the test data designated as required.

Label design proposals and observed results clearly.

Explain your work

Use these prompts to reflect on your decisions and what you learned.

Which part of your filesystem incident record needed the most judgement?
What observation or assumption changed your approach?
What would you improve, and what have you not verified?

Describe this as a personal project in your portfolio.

Useful resources

Use these resources to deepen your understanding and check key details.

Official certification objectives

Review the current provider requirements and relevant subject areas.

Explore external learning resources

Find relevant providers and check features, access requirements and costs.

A useful starting point

Use a disposable VM with a small separate test volume. Fill it with harmless generated files, keeping the operating-system filesystem unaffected.

What a good result looks like

The diagnosis identifies the constrained resource rather than deleting files at random.
The recovery preserves the test data designated as required.

Finish the project

Save sanitised evidence, then remove the lab instances or revert to the clean snapshot. Remove temporary accounts and credentials.

Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.