Scheduled Tasks, Repair Jobs, Metadata Rebuilds, Blob Maintenance, and Operational Housekeeping: Guided Hands-On Workflow and Core Operations

1. Disposable lab scope

This lesson does not require production data, a public endpoint, a cloud account, or Pro. Use the same loopback-only archive installation you have used in earlier chapters, or a fresh equivalent. Keep the instance disposable because task work is server-side state mutation.

2. Preflight: prove environment before task creation

1. Confirm Nexus is reachable only on your intended local/private interface.
2. Record version, edition, Java runtime, database, data directory, blob store, and free disk in environment.txt.
3. Confirm no migration, upgrade, restore, cleanup/compaction, or backup is currently running.
4. Open the Tasks page and record all existing names, types, states, schedules, next run, last run, and last result.
5. Open the live Create task menu and compare it with current documentation.

This inspection proves that the task type you intend to use actually exists on your instance.

3. Create tiny repository evidence

Create task-lab-blobs and a Raw hosted repository task-lab-raw using the supported UI. Upload two tiny text assets:

learner-example/tasks/keep/build-001.txt
learner-example/tasks/keep/build-002.txt

Record their SHA-256 hashes before upload. Verify each from a fresh client request. The purpose is not to test cleanup; it is to have known content whose consistency can be checked after maintenance.

printf 'task-lab build 001\n' > build-001.txt
printf 'task-lab build 002\n' > build-002.txt
sha256sum build-001.txt build-002.txt

curl -fsS -o verify-001.txt \
  'http://127.0.0.1:8081/repository/task-lab-raw/learner-example/tasks/keep/build-001.txt'
sha256sum verify-001.txt

4. Inventory the current task table

Build a small evidence table rather than copying every task type into notes:

name | type | system/operator | enabled | schedule | state | last-result | scope
-----|------|-----------------|---------|----------|-------|-------------|------
...

Pay attention to auto-created cleanup tasks. System-created tasks can return after restart and should not be treated like ad-hoc definitions you own. Record this distinction because it affects lifecycle management.

5. Task 1: harmless H2 backup task

For this Community/H2 lab, create Admin - Backup H2 Database with a name such as LAB - H2 backup - manual. In the task's Location field, use a dedicated writable relative lab path and record where the task resolves its output. Keep the frequency Manual for the first run and do not use an employer/shared backup target.

Before running, record the destination directory listing and the two Raw asset hashes. Predict:

• database backup files should appear in the chosen backup location;
• Raw artifact hashes should not change;
• the task should gain last-run/result evidence and a task log.

6. Run, observe, verify

Run the task manually from the UI. Watch its task state. When complete, record the last result and inspect the backup directory. Then verify the two Raw assets again. Your evidence should demonstrate three independent facts: the task executed, backup output exists, and unrelated repository content remained stable.

Inspect $data-dir/log/tasks and nexus.log. Do not publish logs blindly; redact usernames, internal paths, hostnames, or other environment details before sharing.

7. Optional Community-compatible API inspection

If your current edition exposes the documented list/get endpoints, use a temporary least-privilege account with nx-tasks-read to inspect task state. Do not hardcode credentials.

export NEXUS_URL='http://127.0.0.1:8081'
export NEXUS_USER='task-observer'
read -rsp 'Temporary task-observer password: ' NEXUS_PASS; echo

curl -fsS -u "$NEXUS_USER:$NEXUS_PASS" \
  "$NEXUS_URL/service/rest/v1/tasks" \
  | tee tasks-before.json

Locate your task ID in the returned items, then GET that task. The API is useful for evidence collection; do not turn this lesson into infrastructure-as-code. Chapter 20 covers provisioning and automation patterns.

8. Task 2: safe file-blob temporary-file cleanup

Create Admin - Delete blobstore temporary files for the dedicated task-lab-blobs file blob store if that task is present in your version. This task applies to file blob stores. Ensure no upload is in progress and the blob store is used only by the disposable lab repository.

Run it once manually. In a healthy tiny lab it may have nothing to delete. A no-op can still be a valid exercise because the objective is to observe task configuration, execution state, logs, and unchanged repository content.

9. Convert only the harmless task to a short-lived schedule

After the manual H2 backup run succeeds, change its schedule to a one-time or daily schedule appropriate for the lab and record Next run. You are proving scheduler behavior, not creating a permanent maintenance policy. Restore it to Manual or disable/delete the lab task during cleanup.

Do not schedule Repair tasks for this exercise.

10. Metadata and browse maintenance: identify before execute

Now inspect the current Repair task catalog. Examples can include rebuild repository browse, rebuild repository search, Maven metadata rebuild, npm metadata rebuild, Yum metadata rebuild, Composer metadata rebuild, or repository trim browse tree. The exact list depends on version, format, database, and edition.

For each visible task, answer three questions:

1. What symptom would justify it?
2. What state does it rebuild?
3. What state does it not repair?

Because the disposable Raw repository is healthy, there is no justified reason to execute a Repair task. This is the correct operational outcome. The prompt requires metadata/browse maintenance only where current docs support it; current docs explicitly caution against routine Repair execution.

11. Free simulation: interpret a search rebuild without mutating Nexus

Use this synthetic task-log fixture to practice evidence interpretation:

2026-08-26 02:00:00 INFO  [repository.rebuild-index] repository=demo-maven status=STARTED
2026-08-26 02:02:10 INFO  [repository.rebuild-index] components=18420 assets=55112 progress=68%
2026-08-26 02:03:44 WARN  [repository.rebuild-index] cancellation requested
2026-08-26 02:03:45 INFO  [repository.rebuild-index] status=CANCELLED

Current documentation states that cancelling Repair - Rebuild repository search leaves a partially rebuilt search index. The correct next step is not to assume the old index was restored. Preserve evidence, understand why it was cancelled, and run the supported rebuild again in a suitable window if the incident still requires it.

12. Before/after evidence matrix

13. Challenge: choose the control from the symptom

For each scenario, choose inspection, routine Admin task, format metadata rebuild, search/browse rebuild, data-repair workflow, or no task:

1. Exact Maven artifact URL works, but Search does not return the component after a documented migration issue.
2. Disk free space did not increase after logical cleanup.
3. An npm package's generated metadata is corrupted while the package assets remain present.
4. A restore left database metadata and blob content demonstrably inconsistent.
5. A user reports a 401 from a package client.

Expected reasoning: 1 may justify search rebuild after evidence; 2 investigate soft deletion/compaction; 3 may justify npm metadata rebuild; 4 is recovery/data-repair territory; 5 is authentication/authorization, so a maintenance task is the wrong tool.

14. Lab cleanup

1. Return the H2 backup task to Manual or remove the lab-created task through supported UI controls.
2. Remove the lab temporary-file task if you created it solely for training.
3. Delete task-lab-raw through Nexus, then delete task-lab-blobs only after Nexus confirms it is unused.
4. Remove temporary credentials and local verification files.
5. Keep the evidence packet outside the disposable Nexus data directory.
6. Never delete task records, database rows, or blob files directly.

15. Knowledge check

16. Summary and next step

You can now inspect the live task catalog, run a harmless task with before/after evidence, verify task logs, and refuse unnecessary Repair work. Lesson 3 turns these mechanics into a maintenance operating model: who may schedule what, how often, against which scope, and with which performance/recovery tradeoffs.

Official references and version notes

• Sonatype: Tasks — task states, schedules, logs, current task catalog, and Repair-task cautions.
• Sonatype: Tasks API — list/get/run/stop operations and Pro-only create/update/delete/template endpoints.
• Sonatype: Data Repair Tasks — current plan/execute workflow and recovery-only use.
• Sonatype: Cleanup Policies — cleanup-system tasks, soft deletion, and compact-blob-store reclamation.
• Sonatype: Privileges — nx-tasks-read, nx-tasks-run, create/update/delete task privileges, and least-privilege design.
• Sonatype: Nexus Repository 3.95.0–3.95.2 Release Notes — dated feature and maintenance-task changes.
• Sonatype: System Requirements — Java 21, database guidance, storage, and capacity prerequisites.
• Sonatype: Backup and Restore — context for why database backup alone is not complete recovery.