Based on a LinkedIn post originally published on 1 April 2026
The toolset used on my home-lab platform is intentionally small and purpose-driven.
Tools are selected to help me understand, diagnose and operate the system. They are not introduced simply because they are popular, provide an attractive interface or promise to automate another part of the environment.
Each tool must answer a specific operational question.
The objective is not to own the largest toolbox. It is to ensure that every tool has a clear role and makes the platform easier to understand.
Tools create operational architecture
A tool is never completely external to the system it operates.
Once introduced, it creates dependencies:
- someone must install and update it;
- its configuration must be protected;
- its access model must be understood;
- its output must be interpreted;
- and operators may gradually become dependent on the view it provides.
A new tool may simplify one task while increasing the complexity of the overall platform.
New tool | +---- Installation +---- Configuration +---- Authentication +---- Updates +---- Data storage +---- Monitoring +---- Failure behaviour +---- Operator knowledge | v Net value must exceed total operational cost
This is why I prefer a small collection of tools whose responsibilities do not overlap unnecessarily.
The operational questions
The toolset on HG000009 is built around four recurring questions:
QUESTION TOOL ---------------------------------------- -------- How is the system configured? Webmin Can the data be recovered? Borg Why is the system behaving this way? perf What is happening right now? Glances
These questions cover administration, recovery, deep diagnosis and immediate visibility without attempting to place the entire platform behind one abstraction.
Webmin: visible and controlled administration
Webmin provides a web-based administrative view of the system.
Its role is not to replace knowledge of Linux configuration or to invent a separate operating model. It provides visibility into system state and a controlled way to perform selected administrative tasks.
A useful administrative interface should help answer:
- Which services are enabled?
- How is storage configured?
- Which scheduled operations exist?
- What is the current package and system state?
- Which configuration will change if an action is performed?
The interface remains useful only while the relationship between its controls and the underlying operating system remains understandable.
A graphical interface should expose system mechanics more clearly—not create a second, mysterious configuration layer.
Because an administration interface is privileged, its exposure must remain tightly constrained. Convenience does not justify making broad system control reachable from ordinary networks.
Borg: backup designed around recovery
Borg provides efficient, encrypted backups with explicit control over retention, verification and restoration.
Backup tooling is often evaluated according to whether scheduled jobs complete. That is necessary, but incomplete.
The operational question is not:
Did a backup command exit successfully?
It is:
Can the required data be restored to the required location within an acceptable period using the information available during an incident?
Borg supports several properties important to that objective:
- Deduplication reduces unnecessary duplication between backup archives.
- Encryption protects backup contents when stored outside the immediate system.
- Retention policies determine which historical recovery points remain available.
- Integrity checking provides evidence that archives remain readable.
- Explicit restoration allows recovery procedures to be tested rather than assumed.
The tool supports recovery, but it does not define the complete recovery strategy. That still requires decisions about scope, frequency, retention, key protection, off-system copies and restoration testing.
perf: investigate below the application layer
perf provides low-level performance analysis through Linux performance counters and tracing capabilities.
It becomes valuable when high-level monitoring can describe a symptom but cannot explain it.
For example, a dashboard may show that CPU utilisation is high. That does not establish:
- which code path is consuming the processor;
- whether time is spent in user or kernel space;
- whether scheduling behaviour is involved;
- whether cache misses are significant;
- or whether the observed process is waiting on another subsystem.
High-level observation: CPU utilisation is 95% Deeper questions: Which process? Which function? User space or kernel? Useful work or contention? Expected load or abnormal behaviour? What changed?
perf helps move the investigation from resource consumption toward system behaviour.
It is not intended to run constantly merely because detailed data can be collected. Deep instrumentation has a cost and should be applied when the operational question justifies it.
Glances: immediate situational awareness
Glances provides a quick, consolidated view of current system activity.
It helps answer the first question during an investigation:
What is the system doing right now?
The answer may include:
- CPU and load behaviour;
- memory and swap use;
- active processes;
- disk and network activity;
- filesystem utilisation;
- and unusual changes in resource consumption.
This broad view helps determine where a deeper investigation should begin.
Glances does not replace long-term metrics, logs or specialist profiling. Its value is rapid orientation.
A good overview tool helps select the next question. It should not pretend that one screen contains the complete diagnosis.
From visibility to explanation
The tools form a progression rather than four unrelated products.
Glances
What is happening now?
|
v
Webmin and system configuration
How is the system expected to behave?
|
v
perf
Why is the low-level behaviour occurring?
|
v
Borg
If the state cannot be repaired safely, can it be recovered?Not every incident follows this exact sequence, but each tool occupies a recognisable place in the operational model.
Avoid overlapping sources of truth
Operational complexity grows quickly when several tools can change the same configuration.
If a setting can be modified through a command line, a web interface, a configuration-management system and an independent automation script, the current value may no longer reveal which mechanism owns it.
Configuration changed manually
|
Automation restores previous value
|
Web interface shows the restored value
|
Operator changes it again
|
Ownership becomes ambiguousThe problem is not that multiple interfaces exist. It is that responsibility for the desired state has not been defined.
Each tool should have a clear relationship with the source of truth. Visibility, diagnosis and configuration control should not compete silently.
Abstraction should reduce work without erasing causality
Abstraction is valuable. Modern infrastructure would be impossible to operate if every action required direct manipulation of hardware and kernel structures.
The concern is not abstraction itself. It is abstraction that prevents the operator from connecting an action to its effect.
A useful tool should make it possible to answer:
- What did the tool change?
- Where is that state stored?
- How can the result be verified independently?
- What happens if the tool becomes unavailable?
- Can the operation be performed or reversed without it?
If a tool makes an action easy but makes its consequences mysterious, it has reduced interaction cost by increasing diagnostic cost.
Operational simplicity is deliberate
A small toolset does not happen automatically. Tools accumulate because each addition solves a real problem at the moment it is introduced.
The platform eventually contains several dashboards, backup mechanisms, configuration interfaces and monitoring agents with overlapping responsibilities.
Maintaining simplicity requires periodic removal as well as selection.
A tool should remain only if it:
- answers a continuing operational question;
- provides information or control not already available more effectively elsewhere;
- has an understood security and maintenance cost;
- and preserves the operator’s ability to understand the underlying system.
The rule I apply is straightforward:
If a tool hides behaviour instead of helping explain it, it does not belong in the platform.
This does not produce the most fashionable toolchain. It produces one that remains observable, debuggable and understandable when something goes wrong.
Operational maturity is not measured by the number of tools installed. It is measured by whether the people responsible for a system can still explain its state, diagnose its behaviour and recover it under pressure.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment