Beginner to intermediate · Roughly 14–30 hours, plus reading and teach-back.
Autistici/Inventati's shutdown is the historical catalyst for this manual, but the lesson is larger than any one project. Movements and community organizations need to understand the systems they depend on well enough to map them, maintain them, back them up, move them, preserve what matters, and pass that knowledge on.
A server disappears and a collective suddenly loses access to a website, an archive, a communication tool, organizing infrastructure, documentation, or some other piece of the machinery through which it does its work. Maybe the machine failed, maybe an account was suspended, maybe a provider decided it no longer wanted to host the project, or maybe equipment was seized. Sometimes the reason is much less dramatic: the person who maintained everything leaves, burns out, loses access, or simply does not have the capacity to keep doing it anymore. Whatever the cause, the immediate question is usually the same: How do we get the server back?
That question makes sense in an emergency, but it can also keep us focused on the wrong problem. If the answer is simply to recover that particular server, then we have restored the thing that was lost without necessarily changing the conditions that made its loss so consequential. We are still dependent on the same machine, the same provider, the same credentials, the same documentation, or the same person who knows how everything works. The next disruption can therefore produce the same crisis all over again, even if the original server has been successfully restored.
The goal, then, is not to build a server that cannot be killed. There is no such server, and pretending otherwise would only create another kind of fragility. Machines fail, accounts disappear, providers change their terms, equipment gets seized, hard drives die, systems become inaccessible, and people leave projects. Infrastructure is always vulnerable to disruption. What we can change is how much the disappearance of any one piece of infrastructure matters.
That requires thinking about resilience at a different scale. Instead of asking only how to make a particular server harder to destroy, we can ask how to make the capacity to reproduce that server harder to destroy. The question becomes less about protecting one machine forever and more about building enough distributed knowledge that losing one machine does not mean losing the ability to rebuild what it did.
There are already enormous numbers of servers in the world, so the problem is not a shortage of machines waiting to be built. What movements often lack is distributed capacity: enough people who understand infrastructure well enough to maintain it, repair it, reproduce it, document it, and teach someone else.
That distinction matters because adding hardware does not necessarily create resilience. A backup that nobody knows how to restore is not much of a backup, and documentation that only makes sense to the person who wrote it is not much of a collective survival strategy. A system that technically belongs to a collective but can only be maintained by one exhausted volunteer is still organized around a dependency, regardless of how decentralized its architecture might appear from the outside.
The more useful question, then, is not simply how many servers a movement has, but how many people can reproduce what those servers do. A server represents a particular configuration of hardware, software, networks, credentials, knowledge, and labor. If that entire combination exists in only one place, then the infrastructure remains vulnerable even if the machine itself is perfectly maintained. If the knowledge required to recreate it is spread among many people, documented clearly, and passed between collectives, the same infrastructure can begin to exist in more than one place at once.
The project is therefore not simply to build one better server. It is to build the capacity for many people to understand how servers work and to make that capacity increasingly ordinary within our movements, rather than something reserved for a handful of specialists.
This is what it means to become the thousand servers. The model is not one server with another server sitting somewhere as a backup. It is one person learning something, teaching someone else, and watching that knowledge move outward until what once depended on a single person or machine can be reproduced by many people in many places.
The unit of resilience is not really the machine. It is the person who can reproduce the machine, or at least the person who knows enough to begin rebuilding it and knows who to ask when they reach the edge of their own knowledge. If you learn how to register a domain, administer a machine, make and restore backups, secure an account, read logs, troubleshoot a broken service, or document a system, you have acquired a piece of infrastructure that can travel with you. The machine remains in one location, but the ability to reproduce what it does can move between people and collectives.
This is where each one, teach one becomes more than a principle for political education. Applied to infrastructure, it becomes a strategy for making technical capacity reproducible. You learn something, document it, teach someone else, let them practice it, and then help them reach the point where they can pass it along again. What matters is not simply that more people know things, but that knowledge stops being trapped inside the person who happened to learn it first.
That also means resisting the temptation to make ourselves indispensable. Being the person everyone has to call when something breaks can feel like a sign that we are contributing something important, but it can just as easily mean that we have become a bottleneck. If a collective cannot maintain its own infrastructure when one person leaves, then that infrastructure was never as collective as it appeared. The goal should be to make ourselves increasingly unnecessary by making the knowledge we carry increasingly available to other people.
When we talk about a server, we tend to picture the physical object first: a computer sitting somewhere, storing files and running services. But a server can hold an archive, host a website, carry communications, authenticate users, publish documents, coordinate work, and preserve years of collective memory. When that infrastructure disappears, what is lost is therefore not simply hardware. It can mean losing access to records, writing, relationships, documentation, and the accumulated memory of a project.
There is another layer of infrastructure that is easier to overlook because you cannot see it sitting in a rack. Someone knows how the server works. Someone knows where the credentials are stored, which services are running, what depends on what, where the backups live, and what needs to happen when something breaks. Someone knows what went wrong the last time the system went down, which configuration was changed, which strange error can be ignored, and which seemingly minor warning means something is about to fail. Someone knows how to restore the system, or at least knows where to begin looking when restoration becomes necessary.
That knowledge is infrastructure too, and it can be just as concentrated as the machines themselves.
This is where technical decentralization can become misleading. A collective might operate ten servers spread across different machines and locations while still depending on one person who understands how all ten work. The hardware may be distributed, but the knowledge required to maintain it is not. In that situation, the system still has a single point of failure, only the point of failure happens to be a human relationship rather than a piece of hardware.
None of this is an argument against expertise. Movements need people with deep technical knowledge, just as they need people with deep knowledge of organizing, communications, legal support, logistics, media, or any other specialized work. The problem begins when expertise becomes dependency: when knowledge accumulates around a person instead of circulating through a collective, when the person who knows how something works becomes the only person who can fix it, or when every new crisis requires finding the same person and hoping they are available.
A technically distributed system can therefore remain socially centralized. If we want infrastructure that actually contributes to autonomy, we have to think about both sides of that equation.
None of this requires everyone to become an expert in everything. A movement does not need one person who understands every layer of its technical infrastructure, and expecting that would simply reproduce another impossible standard. What it needs is a web of people who understand different pieces of the system and are capable of sharing those pieces with one another.
One person might understand networking while another is good at backups. Someone else might know hardware, another might understand security, and someone else might be particularly good at documenting complicated systems in ways that a beginner can actually follow. Someone may know how to explain Linux to a person who has never opened a terminal without making them feel like they have wandered into a foreign language class halfway through the semester. None of these people needs to hold the entire system inside their head for the collective to function.
What matters is that their knowledge connects and that the connections do not depend entirely on any one person.
That makes documentation part of infrastructure, and it makes teaching part of infrastructure too. Writing down the boring details matters because those details are often exactly what disappears when the person who knew them leaves. Explaining why something works instead of simply giving someone the command to copy matters because understanding makes it possible to troubleshoot when circumstances change. Making room for beginners matters because every person who learns enough to maintain one small piece of infrastructure becomes another point through which knowledge can move.
Technical autonomy is therefore not achieved when a handful of people become extremely good at technology. It becomes possible when technical knowledge circulates widely enough that the loss of any one person does not take the collective's capacity with them.
This also means taking failure seriously without treating failure as evidence that people should never have tried. Someone will misconfigure something. Someone will delete the wrong file. Someone will discover that the backup they assumed existed was never actually usable. Someone will have to rebuild a system from scratch after making a mistake they will not make twice. Those experiences are part of learning. The important question is whether the lesson disappears with the person who learned it or becomes part of the collective knowledge available to whoever comes next.
The practical work starts with learning how the machinery underneath our movements actually functions. The field guide that follows is not meant to turn everyone into a professional systems administrator, nor is it a checklist for constructing some perfectly autonomous technological utopia. It is a starting point for making the infrastructure we depend on less mysterious and the knowledge required to maintain it less concentrated.
This is also not a demand that every collective become an internet service provider or administer every service it uses. Infrastructure always has dependencies. The practical goal is to make those dependencies visible and deliberate: know who controls the domain, where DNS is hosted, where data lives, who can recover access, which copies exist outside the provider, and what happens when any one part disappears.
You do not need to understand every layer of a system before you begin working with it. You need somewhere to start, enough patience to make mistakes and learn from them, and people around you who are willing to share what they know. The first thing you build does not need to carry an entire collective's communications or host an archive that hundreds of people depend on. It can be a place to experiment, something you build and break and rebuild until the machine becomes less mysterious and the process of troubleshooting becomes less intimidating.
That distinction matters because the first goal is not perfection. It is familiarity. There is a difference between knowing that something can be done and knowing enough about how it works to attempt it yourself, recognize when something has gone wrong, find your way through the problem, and eventually explain the process to someone else.
The course combines these conceptual sections with twelve practical lessons. You will map a real dependency chain, inspect DNS, use SSH on a disposable Linux machine, serve a small site, examine network exposure, build and restore an independent backup, destroy and rebuild a disposable service, migrate it, distribute administration, preserve published work, troubleshoot a local network, examine an alternative network model, and teach a skill to somebody else.
The exercises deliberately distinguish learning environments from production. Do destructive work only on systems you are allowed to lose. Keep private data and real organizations out of experiments until you understand the operational and security consequences. When a procedure depends on a specific operating system, software version, or provider, verify the current documentation rather than assuming an old command remains correct.
The purpose is not to memorize commands. It is to develop enough shared technical capacity that a project is less likely to become helpless when a provider, account, machine, domain, or administrator disappears.
The field guide is an invitation to cross that line.
Draw the service path and the control/recovery path behind a real website or project
Distinguish account ownership, administrative access, billing, data custody, export, and recovery responsibility
Identify technical, administrative, and human single points of failure before an emergency
Mark unknown dependencies instead of guessing
Set a practical Recovery Point Objective and Recovery Time Objective for important data and services
LEARN
Autonomous infrastructure starts with an inventory, not a purchase. Most projects already depend on a substantial stack: domain registration, authoritative DNS, hosting, web software, databases, file storage, email, repositories, build and deployment systems, identity providers, payment systems, backups, recovery channels, and the people who know how to operate them.
Separate the service path from the control path. For a typical web request, a browser asks a recursive DNS resolver for a name. If the answer is not already cached, that resolver follows DNS referrals until it reaches authoritative DNS and obtains the relevant record. The browser then connects to the resulting service endpoint, which may be a CDN, reverse proxy, host, web server, application, database, or object store. The registrar is not normally a hop in that request. It is part of the control plane: it controls the registration and, usually, the delegation to the authoritative nameservers. A project can therefore remain online for a while even after losing the account needed to renew the domain or change its nameservers.
A dependency map should show more than vendor names. For each component, record the account holder or organizational owner, who can administer it, where recovery messages go, who pays or renews it, where authoritative data lives, how that data can be exported or independently backed up, where documentation lives, and what another person would need to take over. Ownership and access are not the same thing. A domain can be registered in one person's name, paid from another person's card, administered through a third person's account, and recoverable only through an inbox or second factor nobody else can reach.
People belong on the map, but shared passwords are not a resilience strategy. If a provider supports separate administrator identities, use them. Give people only the access they need. Record the custody of recovery methods without copying passwords, private keys, one-time codes, or recovery codes into the map itself. If only one person understands DNS, only one person possesses an authorized recovery method, or only one person knows which backup actually restores, the project still has a human single point of failure.
Two recovery ideas are useful even for small projects. Recovery Point Objective (RPO) is the point in time to which data needs to be recovered after an outage. In practical terms, it asks how much recent data loss is acceptable. Recovery Time Objective (RTO) is the target time for restoring the system or service after disruption. It includes more than booting a replacement server: detecting the problem, recovering access, provisioning infrastructure, restoring data, changing configuration or DNS where necessary, and verifying that the service actually works can all consume recovery time.
A stated RPO is not satisfied merely because a backup job is scheduled that often. Backups can fail, omit data, or be impossible to restore. A stated RTO is not credible until somebody has worked through the recovery path. The map is where you identify what needs to be tested later.
Treat the dependency map as a living operational document. Update it when providers, administrators, domains, recovery methods, deployment systems, or data locations change. An accurate map that contains several honest “unknown” entries is more useful than a polished diagram full of assumptions.
DO
Pick one real project you help maintain. This lesson is discovery, not reconfiguration: inspect what exists before changing anything.
Create a dependency table. Useful columns are: dependency; purpose; account holder or organizational owner; administrators; billing or renewal; authoritative data location; export or backup method; account-recovery method and custody; documentation location; and single point of failure or unknown. Do not put passwords, private keys, authentication secrets, or recovery codes in the table.
Draw the normal service path separately from the control and recovery path. For a website, trace the name through DNS to the public service endpoint and onward to the application and its data stores. Separately trace who can renew the registration, change the nameserver delegation, edit authoritative DNS, deploy code, restore data, and recover each important account. For email, include the MX destination and the account or provider that controls the mail service.
Trace at least one real user action end to end. If a layer is managed by somebody else or you cannot determine what happens there, label it managed or unknown. Do not invent a box to make the diagram look complete.
Mark every dependency that has only one administrator, one credential or recovery holder, one independent copy, one provider, one payment method, one recovery inbox, one device holding the only second factor, or one person with the necessary knowledge. Also mark shared failure domains: several different services depending on the same registrar account, email inbox, payment card, password manager, cloud account, or administrator can fail together.
Write a simple recovery target for the important data and service. State an RPO in plain language, such as “we can tolerate losing at most one day of new posts,” and an RTO, such as “the public archive should be available again within two days.” These are targets, not promises. Later lessons will test whether the backup and recovery process can actually meet them.
Choose the three highest-impact unknowns or single points of failure on the map and write one concrete next action for each. The action might be verifying the registrar account, creating a second authorized administrator, documenting a deployment process, making an off-provider backup, or testing a restore. Do not try to fix the entire stack during this lesson.
TEST
Using only the dependency map and its documentation, can another maintainer identify the domain registrar or reseller, authoritative DNS, public hosting path, source repository and deployment path, authoritative data stores, independent backups, and account-recovery channels? Can they distinguish a failure that causes temporary unavailability from one that could cause permanent data loss or loss of control?
TEACH
Give the map to another person who did not make it. Without filling in the answers for them, ask them to trace both paths: first how a user reaches the running service, then how the organization would recover control or rebuild it after a failure. Every place they cannot continue from the map is either an unknown dependency or a documentation gap.
Service/request path and control/recovery path are mapped separately
Registrar or reseller, authoritative DNS, hosting, application, authoritative data, repository/deployment, and backups are identified
Account ownership, administrative access, billing or renewal, recovery, export, and documentation paths are recorded
Passwords, private keys, authentication secrets, and recovery codes are not stored in the dependency map
Human and shared failure domains are marked
Unknown dependencies are explicitly marked for verification
A practical RPO and RTO are recorded for important data and service
Three concrete risk-reduction actions are recorded
Another person can explain both paths without relying on the original maintainer
Resources
ICANN Lookup RDAP-based registration lookup for generic top-level domains. Public registration fields may be redacted; do not treat the result as a complete ownership record.
Modern infrastructure is designed to be easy to consume. That is useful, but it can make the systems underneath it difficult to reason about.
You register a name, click deploy, connect a repository, and receive a working site. None of that requires you to see the domain delegation, recursive DNS lookup, authoritative answer, network connection, TLS handshake, listening socket, reverse proxy, application process, or database connection underneath the interface. The abstraction is doing its job. The problem begins when a project has no way to look beneath that abstraction when something fails or needs to move.
This section develops enough technical literacy to trace what is actually happening without requiring you to memorize the whole internet.
A domain name is a name, not a server. Registration determines who controls the name and which nameservers are delegated authority for it. DNS turns names into records that lead clients toward services. A web request may then reach a CDN or reverse proxy before it reaches the machine or application you think of as “the server.” That application may depend on databases, object storage, identity providers, or other services somewhere else entirely. Each layer can fail independently, and several layers can be healthy while the overall service is still unusable.
The same principle applies to remote administration. SSH is not “the server.” It is an encrypted protocol used to establish a connection to an account on a machine. Your authentication key can prove your identity to the remote system; the server's host key lets your client check the identity of the machine it reached. Once connected, ordinary Linux inspection tools let you ask concrete questions: what system is this, who am I, where am I, what is running, what is listening, how much storage remains, and which service produced an error?
The goal is not memorization. Commands are searchable, software changes, and different systems expose the same information in different ways. The durable skill is forming a model of the system and choosing an observation that can distinguish one failure from another.
If a website fails, separate the questions. Does DNS return an answer? Is it the answer you intended? Can the client establish a connection to the service endpoint and port? Does the TLS handshake succeed for the hostname? Does the web server or reverse proxy return an HTTP response? Is the application healthy? Can it reach the data and services it depends on? A failed ping alone does not prove that a web service is down; ICMP may be filtered while HTTPS works normally.
Work from the outside inward and change one layer at a time. Diagnosis is evidence gathering, not a sequence of increasingly desperate button presses. The same habit makes migrations and recovery safer because you know which layer you are changing, what should remain untouched, and what observation will tell you whether the change worked.
Distinguish registrar, registry, parent delegation, authoritative DNS, recursive resolver, and web or mail host
Read the DNS records that commonly control web and mail delivery
Use RDAP and dig to compare delegation, authoritative answers, and recursive answers without changing anything
Understand TTL, cached negative answers, and stale-answer behavior well enough to plan a later migration
Preserve the actual DNS configuration before changing it
LEARN
DNS is a distributed naming system. It does not contain your website, and the company where you registered a domain is not necessarily the company answering DNS queries for it.
The registrar is the organization through which the registrant manages a domain registration. The registry operates the registration database for a top-level domain such as .org or .media. The parent zone delegates a domain to particular authoritative nameservers. Those authoritative nameservers publish the records in the domain's zone. Recursive resolvers obtain answers for clients, usually cache them, and may themselves use forwarders. A web host is where the website or application runs. One company may perform several of these jobs, but the jobs remain distinct.
The delegation in the parent zone and the NS records published inside the child zone are related but not identical pieces of data. They should normally agree. If they do not, different parts of the DNS system can appear to tell different stories. That is why troubleshooting sometimes requires looking at the delegation path as well as querying the authoritative servers directly.
For generic top-level domains, ICANN made RDAP the definitive registration-data service on January 28, 2025, replacing WHOIS as the standard source for gTLD registration information. ICANN Lookup is an RDAP-based way to identify the registrar and whatever registration data is publicly available. Country-code domains may have different registration-data arrangements, so do not assume every TLD exposes the same fields.
Common DNS records have specific jobs. A maps a name to an IPv4 address. AAAA maps it to an IPv6 address. CNAME aliases one name to another name; it is not an IP address. MX identifies mail exchangers and includes preference values. TXT carries text and is widely used for verification and mail policy. NS identifies nameservers for a zone. CAA can restrict which certificate authorities may issue certificates for names in the domain. SRV can describe the location of some named services. Modern deployments may also use SVCB or HTTPS records, but the basic troubleshooting method is the same: identify the record, understand what it means, and follow what it points to.
TTL is the amount of time a DNS record may normally be cached before the source should be consulted again. It is not a global countdown and it does not create an instant “propagation” moment. If you lower a TTL before a migration, a resolver that already cached the old answer can keep it until the old TTL expires. Negative answers such as “this name does not exist” can also be cached. Some recursive resolvers may deliberately serve stale data after TTL expiry when authoritative servers cannot be reached, so TTL is a planning tool, not a promise that no old answer can appear after a particular second.
DNS troubleshooting works best when you separate questions. Ask what the parent has delegated. Ask what the authoritative servers say. Then ask what a normal recursive resolver returns. In a full dig response, the aa flag indicates an authoritative answer. A mismatch among delegation, authoritative data, and recursive answers gives you evidence about where the problem actually lives.
Public DNS queries are not a reliable way to enumerate an entire zone. Do not treat dig ANY, a handful of record-type queries, or a public lookup service as a backup of DNS configuration. If you administer the zone, use the DNS provider's export function or control panel to preserve the complete configuration before changing it.
DO
Pick a domain you control or are authorized to inspect. This lesson is read-only. Use ICANN Lookup or the applicable registration-data service to identify the registrar or registration provider. Use DNS itself to identify the nameservers rather than assuming the registration lookup is your authoritative source for current DNS behavior.
On a system with dig, run dig example.org NS, dig example.org A, dig example.org AAAA, dig example.org MX, and dig example.org TXT. For a web hostname such as www.example.org, also check A, AAAA, and CNAME as appropriate. Use dig +short for a compact view, but save at least one full result so you can inspect flags, TTLs, and the answer and authority sections. On systems without dig, use nslookup or another trusted DNS inspection tool and note that the output will differ.
Trace the delegation path with dig +trace example.org NS or dig +trace example.org A. You do not need to memorize every line. Identify where the root refers the query to the top-level domain and where the parent refers it to the domain's nameservers.
Choose one authoritative nameserver and query it directly without requesting recursion, for example dig @ns1.example.net example.org A +norecurse. Inspect the response for the aa flag. Compare that authoritative answer with dig example.org A, which normally asks the recursive resolver configured on your machine.
If you administer the domain, export or copy the complete DNS zone from the provider before any future change. Do not assume public queries have discovered every record. Preserve web, mail, verification, certificate, and service records, including record names, values, priorities where applicable, and TTLs.
Write down the current TTL for any record you may later change. If you plan to lower it before migration, allow the previous TTL to age out before relying on the shorter value. Also record whether a hostname is currently nonexistent; a cached negative answer can matter if the migration will create that name.
Finally, write a three-column troubleshooting note: parent delegation, authoritative answer, recursive answer. For one web record, record what each layer currently says. If they all agree, you now have a known-good baseline. If they do not, investigate the mismatch before changing anything.
TEST
Can you identify the registrar or registration provider, parent delegation, authoritative nameservers, web records, and mail records; query an authoritative server directly; recognize the aa flag; and explain how an authoritative answer can differ from a cached recursive answer?
TEACH
Give another learner a domain they do not administer. Have them identify the registrar with RDAP where applicable, trace the delegation, query one authoritative nameserver with +norecurse, query the same record through their normal recursive resolver, and explain the difference without logging into any provider account.
Registrar or registration provider identified with RDAP or the applicable registration-data source
Parent delegation and authoritative nameservers identified
A, AAAA, CNAME, MX, relevant TXT, and other important records inspected
At least one authoritative nameserver queried directly with +norecurse and the aa flag recognized
Authoritative and recursive answers compared
Complete DNS configuration exported or copied from the provider before any future change where access exists
TTL, negative caching, and the possibility of served-stale answers are understood
A known-good delegation / authoritative / recursive baseline was recorded
Resources
ICANN RDAP Background and current registration-data access guidance.
Create and protect a modern SSH key pair without moving the private key to the server
Verify a server host key and handle a changed-host-key warning deliberately
Connect as an ordinary user and understand when sudo changes your effective privileges
Identify the Linux environment before assuming which service and log tools it uses
Inspect identity, storage, processes, listening sockets, services, and logs without learning on production
LEARN
SSH provides an encrypted connection to a remote machine and supports several authentication methods. With public-key authentication, your private key stays on the client device. The corresponding public key can be installed for the remote account, commonly in ~/.ssh/authorized_keys. The public key is not a secret; the private key is. Do not copy the private key to the server just because both files appeared next to each other when you generated them.
Current OpenSSH generates an Ed25519 key when ssh-keygen is run without a key type, and ssh-keygen -t ed25519 makes that choice explicit. Using the explicit form also avoids relying on defaults that may differ on older systems or other SSH implementations. Protect an ordinary human login key with a passphrase unless you have a specific reason not to. A stolen encrypted private-key file still needs its passphrase before it can normally be used.
SSH authenticates the server as well as the user. On a first connection, the client can show the fingerprint of the host key presented by the server. Verify that fingerprint through a trusted path when the identity matters, such as a provider console or information obtained directly from an administrator who can inspect the machine. Once accepted, host keys are recorded in ~/.ssh/known_hosts or a system-wide known-hosts file.
A later host-key change is not an annoying dialog to defeat. It may be expected after a rebuild or replacement, but it may also mean DNS now points somewhere else, you connected to the wrong machine, or somebody is intercepting the connection. Verify the new fingerprint and the reason for the change first. Only after that verification should you remove an obsolete entry, for example with ssh-keygen -R hostname.
Use a normal account for routine administration and elevate individual commands with sudo when necessary. Root or equivalent privilege can change almost anything on the machine. The goal is not to avoid administrative privilege forever; it is to know when you crossed that boundary and why.
Before assuming commands, identify the environment. cat /etc/os-release usually identifies the Linux distribution; uname -a shows kernel and machine information. whoami and id show identity; pwd and ls -la orient you in the filesystem; df -h shows filesystem usage; free -h shows memory on many Linux systems; ps aux shows processes; and ss -tulpn shows TCP and UDP listening sockets, with process details when permissions allow.
Service and log commands depend on the system. On systemd-based distributions, systemctl --type=service --state=running lists running services and journalctl -u SERVICE reads a service's journal. Other Linux systems may use different service managers or log files. If a command is absent, that is information about the machine, not an invitation to paste increasingly unrelated commands into it.
DO
Create a disposable Linux VM, old laptop, or temporary VPS. Before changing remote access, confirm that an out-of-band recovery path such as a provider console actually opens. “There is probably a console somewhere” is not a recovery method.
On your own computer, generate a key with ssh-keygen -t ed25519. Give the private key a passphrase. Identify the private file and the corresponding .pub file. You can inspect the public key's fingerprint with ssh-keygen -lf path-to-key.pub. Install only the public key on the disposable server.
Add the public key using the provider's setup flow, ssh-copy-id where available, or the documented authorized_keys procedure for the system. Connect with ssh user@example-host. On the first connection, compare the host-key fingerprint SSH presents with a fingerprint obtained through the provider console or another trusted path before accepting it when possible.
If the server uses the usual OpenSSH host-key paths, the console can show a host-key fingerprint with a command such as sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub when the connection is presenting an Ed25519 host key. Do not assume the server must use that key type; compare the fingerprint for the host-key type actually being presented.
After login, run cat /etc/os-release, uname -a, whoami, id, pwd, ls -la, df -h, and ps aux. Inspect listening sockets with ss -tulpn if available. If the system uses systemd, inspect running services with systemctl --type=service --state=running and choose one service to examine with journalctl -u SERVICE. If it does not use systemd, identify the service manager and log location instead of forcing systemd commands onto it.
If your account has sudo access, run sudo -l to see what it is authorized to do. Use elevation only for a harmless inspection that actually requires it, and compare id with sudo id if you want to see the privilege change explicitly.
Log out and reconnect using your key. On your client, use ssh-keygen -F example-host to locate the host's entry in known_hosts. Write down what you would do if SSH later reported that the host identification changed: stop, verify why the machine's host key changed through a trusted path, compare the new fingerprint, and only then remove the obsolete known-hosts entry if the change is legitimate.
TEST
Can you reconnect using your own private key, explain which key material belongs only on the client, verify the server's host key through a trusted path, locate its known_hosts entry, inspect the Linux environment and service state, and explain what you would do before accepting a changed host key?
TEACH
Create a separate ordinary account for another learner where appropriate and have them connect using their own key. Have them verify the host fingerprint, identify the Linux distribution and service manager, inspect one running service, and explain why neither a shared private key nor blindly deleting a changed known_hosts entry is a sound administration practice.
Disposable machine and a tested out-of-band recovery path are available
Ed25519 key pair created and the private key protected with a passphrase
Only the public key was installed on the server
Server host-key fingerprint was verified through a separate trusted path
known_hosts behavior and the changed-host-key response are understood
Ordinary user used for normal work and sudo boundaries inspected deliberately
Linux distribution and service manager identified
Disk, process, socket, service, and log state inspected
Logout and key-based reconnection succeeded
Resources
OpenSSH manual Primary OpenSSH documentation and manual-page links.
ssh-keygen manual Current key-generation behavior and key-file details.
Infrastructure is learned best in an environment where failure is allowed and bounded.
Do not begin by experimenting on a production service that holds somebody else's writing, membership list, communications, credentials, or only copy of important data. Create a disposable machine or virtual environment whose destruction would be an inconvenience rather than a crisis. Do not reuse unique production data or irreplaceable secrets merely to make the lab feel realistic. If destroying the machine would create an emergency, it is not disposable.
Then make the smallest complete service you can understand.
A static page is enough. One file lets you see the path from a name to a visible result: DNS returns an address, a client establishes a connection to a service endpoint, HTTPS establishes an authenticated encrypted session, the client sends an HTTP request, and a web server returns a file. For the conventional HTTP/1.1 and HTTP/2 path this normally means TCP port 443. Modern HTTP/3 carries HTTP over QUIC, usually on UDP 443. You do not need to master all three protocols in this lesson, but you should not be surprised later when a web server is listening on both TCP and UDP.
Public exposure is not required for every experiment. You can first serve the page locally and prove that the web server works. When you deliberately make it public, use a disposable hostname, publish no sensitive information, and know how you will recover access if a firewall or SSH change locks you out.
Once the page works, inspect what making it reachable actually created. Which addresses is the service listening on? Which TCP and UDP ports exist? Which provider firewall, host firewall, router, or security group can block or permit them? Does the machine have working public IPv6 as well as IPv4? Who updates the web server? Where are its logs and persistent certificate data? How will you notice a full disk or failed renewal?
This is also where you should begin resisting unnecessary complexity. A project that needs to publish a handful of durable pages may not need a database, plugin ecosystem, build service, authentication system, and five external APIs. Another project may genuinely need a dynamic application with multiple editors, forms, search, private areas, structured data, or an API.
Choose complexity because it provides a required capability, not because it was present in the last system you inherited. Every additional runtime, account, database, plugin, build step, and secret is another thing that has to be maintained, backed up, recovered, and taught.
Autonomy is a spectrum. A group can control its domain while continuing to use managed hosting. It can maintain independent backups without running its own server. It can self-host a simple site while outsourcing email. It can operate a VPS while relying on a competent datacenter and upstream network. Each step can increase meaningful control if the people involved understand the dependency and know how to leave it.
The objective of the disposable server is therefore not to prove that you can put a page on the internet. It is to make the layers observable, breakable, diagnosable, and recoverable while the stakes are low.
Trace a web request through DNS, transport, TLS, HTTP, and a web server
Serve a harmless static page from a disposable machine without depending on production
Understand what Caddy automatic HTTPS does and which assumptions its normal public-certificate path makes
Recognize TCP 443 and HTTP/3 over QUIC/UDP 443 as different transport paths
Choose the simplest publishing stack that satisfies a real need
LEARN
A small static page is enough to make the web's layers visible. Start with the simplest path you can observe: a hostname, an address, a network connection, TLS for HTTPS, an HTTP request, a web-server process, and one file.
For HTTP/1.1 and HTTP/2 over HTTPS, the client normally reaches TCP port 443. HTTP/3 carries the same HTTP semantics over QUIC instead of TCP and commonly uses UDP 443. A modern server may therefore have both TCP and UDP listeners associated with the same website. The lesson does not require you to configure HTTP/3, but later socket inspection should not treat UDP 443 as automatically suspicious.
TLS does more than “turn on encryption.” The client checks whether the server presents a certificate it accepts for the hostname it requested, and the resulting connection protects the traffic in transit. That does not prove the application itself is trustworthy or uncompromised. It establishes the identity and encrypted transport for the origin the client is contacting.
Caddy is the recommended web server for this particular beginner exercise because its normal configuration can obtain and renew certificates for public hostnames and redirect HTTP to HTTPS automatically. For the ordinary public HTTP-01/TLS-ALPN path used in this lesson, the hostname's A and/or AAAA records must lead to the server, the relevant ports 80 and 443 must be externally reachable, Caddy must be able to receive traffic on them, and its data directory must remain writable and persistent. Those are not universal ACME requirements: a deliberately configured DNS challenge can obtain certificates without opening those challenge ports.
Caddy also uses a local certificate authority for local/internal names and addresses in ordinary local HTTPS setups. Clients that do not trust that local CA will report certificate errors. Do not confuse “Caddy made HTTPS locally” with “a public browser will trust this certificate.”
nginx is also a good web server and its official beginner guide makes static serving explicit, but public TLS certificate acquisition is a separate task unless you add certificate tooling such as Certbot. Use nginx if you deliberately want to learn that extra boundary. Do not mix Caddy and nginx instructions as though they were interchangeable configuration files.
Those layers can fail separately. Correct DNS can point to a host with no listener. TCP 443 can be blocked while SSH works. IPv4 can work while an incorrect AAAA record sends IPv6-capable clients somewhere else. The server can answer HTTP while certificate issuance fails. Diagnose the layer that is broken instead of changing several layers at once.
Also ask whether the eventual project needs a dynamic application at all. Static files or a simpler publishing system can eliminate databases, runtimes, plugins, secrets, and update paths that provide no required capability. Simpler is not automatically better. Unnecessary complexity is simply another dependency.
DO
Confirm that the disposable machine is actually disposable and that your out-of-band provider console or equivalent recovery path works. Confirm SSH still works before changing any firewall or web exposure.
Create a directory such as /srv/disposable-site and place an index.html inside it with unmistakable non-sensitive test content. Make the file readable by the web-server service account without making the directory world-writable.
Install one web server using its current official documentation. For the simplest version of this lab, use Caddy. A minimal Caddyfile is:
Replace the hostname with a disposable hostname you control. If Caddy is running as a service, validate the configuration with the tooling provided by your installation before reloading it, then confirm the service is running and inspect its logs if it is not.
Before changing DNS, inspect the machine's listeners. Confirm which ports and addresses the web server is using. Then create only the DNS records the machine can actually answer: add an A record for working public IPv4 and add an AAAA record only if working public IPv6 is configured. A wrong AAAA record can make a site appear intermittently broken to clients that prefer IPv6.
For the normal Caddy public-certificate path used here, allow inbound TCP 80 and TCP 443 through every firewall layer that actually filters the machine. Preserve SSH access before altering a host firewall, and keep the provider console available. If the server offers HTTP/3, you may also see UDP 443; do not open unrelated ports just because they exist in an example somewhere.
From a second device or network, request the site over HTTPS. Use a browser and, where available, curl -I https://test.example.org/. Confirm the HTTP status, inspect the certificate presented for the hostname, and verify that the page is your unmistakable test file rather than some default site. If it fails, work in order: authoritative DNS, recursive DNS, network path, listening socket, firewall, web-server logs, TLS/certificate issuance, then the file being served.
If you choose nginx instead, first make static HTTP serving work from the official nginx guide, then follow current certificate-tool documentation for HTTPS. Do not disable certificate verification merely to make the exercise pass.
Finally, for one real project, write the minimum publishing capabilities it actually requires: static pages, multiple editors, media management, search, forms, subscriptions, private content, structured data, or an API. Compare those requirements with its present stack and identify components that exist only because they were inherited.
TEST
Can another device load the disposable page over HTTPS, can you identify the DNS, IPv4/IPv6, TCP or QUIC, TLS, HTTP, process, and file layers involved, and can you explain why the chosen publishing stack is no more complicated than the project requires?
TEACH
Have another person trace a successful request from the hostname through DNS, the selected address, transport, TLS, HTTP, the web-server process, and the file. Then break one safe layer in the disposable environment and have them diagnose it without changing unrelated layers.
Disposable machine and out-of-band recovery path verified before exposure changes
Static test file created with no sensitive content
One intended web server installed and configuration validated
Listening addresses and TCP/UDP ports inspected before DNS changes
Only correct A and/or AAAA records created for working address families
Required web ports opened without losing administrative recovery access
HTTPS and hostname certificate verified from another device or network
Failure diagnosis followed the request path instead of changing multiple layers
Minimum adequate publishing stack for a real project documented
Resources
Caddy automatic HTTPS Certificate automation, local HTTPS, challenge behavior, redirects, and public-hostname requirements.
Identify listening TCP and UDP sockets, owning processes, and bound addresses
Distinguish socket binding, provider firewall, host firewall, routing, and application access control
Check IPv4 and IPv6 exposure separately
Verify update, restart, log, certificate, storage, and administrator-recovery responsibilities
Make firewall changes without accidentally removing the only administration path
LEARN
A service working once is not the same as a service you can maintain. Before anybody depends on a machine, you should be able to account for what is reachable, why it is reachable, what must be updated, where failures are recorded, and how administration is recovered.
A listening socket means a process has asked the operating system to accept traffic on an address and port. A loopback listener such as 127.0.0.1 or ::1 is normally reachable only from the machine itself. A wildcard listener such as 0.0.0.0 or :: can make a service available on network interfaces, but actual reachability still depends on routing and firewalls. Do not infer IPv4 behavior from an IPv6 wildcard or vice versa; operating-system and application settings can differ. Inspect and test both address families.
Exposure has several gates. A cloud provider may filter traffic before it reaches the VM. The operating system may use nftables, UFW, firewalld, iptables compatibility rules, or another firewall. A home router may add NAT or port-forwarding. The application may require authentication even after the network path is open. “The firewall” is therefore not one universal object.
Before modifying a host firewall over SSH, prove that an out-of-band console works and identify the rule that preserves administrative access. Locking yourself out is a memorable lesson, but not a particularly sophisticated one.
Updates are an operational process. Ubuntu Server normally installs the unattended-upgrades package by default and schedules automatic work through APT/systemd timers, but the administrator still needs to know which repositories are covered, whether package or service restarts occur, whether a reboot is recommended, and where failures are logged. Merely adding a third-party repository does not automatically make it eligible for unattended upgrades. On Ubuntu 24.04 and later, needrestart can automatically restart many affected services after upgrades, which is useful but also means updates can cause service restarts without somebody manually typing systemctl restart.
Certificate maintenance depends on the software that owns the certificate lifecycle. Caddy renews certificates it manages as long as its configuration, network validation path, and persistent data remain healthy. Certbot installations normally have a cron job or systemd timer for renewal and can be tested with sudo certbot renew --dry-run. Do not create a second certificate-renewal system for the same site without understanding which tool owns the files and reloads the server.
Logs, storage, and inodes are availability concerns too. A service can fail because a filesystem fills, a database exhausts storage, a log grows without bound, an inode pool is exhausted, a certificate renewal fails, or a process crash-loops. Resilience includes deciding who notices those conditions and what they do next.
DO
On the disposable Linux machine, run sudo ss -tulpn. Record each listening TCP and UDP socket, its bound address, port, and owning process where shown. For the web lab, account explicitly for SSH, TCP 80/443, and any UDP 443 listener used for HTTP/3. Do not label a port “needed” until you can say what process owns it and why it should be reachable.
Identify every network-control layer between the internet and the process. Record the provider firewall or security group if one exists. On the host, determine which firewall system is actually active before editing it. Commands such as sudo ufw status verbose, sudo nft list ruleset, or sudo firewall-cmd --state are useful only when that tool is the one in use. An empty or inactive UFW screen does not prove the machine has no firewall rules.
Before making any firewall change, verify the provider console or equivalent recovery path and preserve the SSH rule you need. Then compare the rules with the listeners. Remove nothing merely because you do not recognize it; investigate first.
Inspect IPv4 and IPv6 addresses and test the intended site from another machine. Where the client supports it, curl -4 -I https://test.example.org/ and curl -6 -I https://test.example.org/ let you test the two address families separately. If IPv6 is not intentionally configured, an AAAA record should not pretend otherwise.
On Ubuntu, run sudo apt update and inspect pending updates with apt list --upgradable. Inspect the automatic-update configuration and timers rather than assuming they work because the package is installed. Check systemctl status apt-daily.timer apt-daily-upgrade.timer and the unattended-upgrades logs when applicable. Record whether automatic service restarts or a reboot would affect the service.
Check filesystem capacity with df -h and inode use with df -i. Inspect recent service logs with journalctl -u SERVICE on a systemd machine. Check ownership and permissions for the served content. Then inspect certificate status and renewal with the tool that actually manages it: for Caddy, inspect its service/logs and persistent data; for Certbot, inspect its timer/cron setup and use sudo certbot renew --dry-run where appropriate.
Finish with a maintenance table containing each public listener, why it exists, which firewall layers permit it, who updates the owning software, where its logs are, how certificates are renewed if applicable, what storage condition could stop it, and how another authorized person recovers administration.
TEST
Can you account for every public TCP and UDP listener, explain its IPv4 and IPv6 reachability through each firewall/routing layer, and show how updates, service restarts, logs, certificates, storage, and administrator recovery are maintained?
TEACH
Have another learner independently inventory the same disposable machine without seeing your list. Compare results and resolve every disagreement by checking actual socket, routing, firewall, update, and service state rather than choosing the answer that sounds safer.
TCP and UDP listeners, bound addresses, and owning processes reviewed
Provider/network and active host-firewall layers identified
Out-of-band recovery and SSH preservation checked before firewall changes
IPv4 and IPv6 exposure tested separately where available
Pending updates and automatic-update coverage inspected
Automatic restart/reboot implications recorded
Logs, filesystem space, inode use, and permissions checked
Certificate owner and renewal mechanism verified
Maintenance ownership and administrator-recovery path documented
Resources
Ubuntu automatic updates Current unattended-upgrades scheduling, repository coverage, reboots, and service-restart behavior.
A service that works today is not automatically resilient.
Resilience begins when the project can lose a component and still recover the capability that component provided within a useful amount of time and without silently losing unacceptable amounts of data.
That requires a clearer vocabulary. A backup is a copy intended for recovery. An archive preserves material for future access. A mirror reproduces public material somewhere else. A replica keeps another live or near-live copy synchronized. A provider snapshot captures a machine, volume, or service state at a point in time. A migration moves a service or its content. These can overlap, but they solve different failures.
A replica is not automatically a backup because deletion, corruption, or malicious changes can be replicated too. A provider snapshot may restore a broken VM quickly while still disappearing with the provider account. A public mirror may preserve every article a reader can see while losing drafts, accounts, database state, server configuration, and unlinked originals. A database dump may preserve posts and settings while omitting uploaded files. The recovery method has to match the capability and failure you are trying to survive.
A real recovery set contains every necessary component and exists across failure domains that do not all disappear together. For an application, that can mean an application-consistent database backup, user files, application/source, configuration, dependency versions, DNS information, documentation, and a protected route to required secrets. It also needs enough history to recover from a problem discovered late. A single “latest” backup can faithfully preserve yesterday's corruption.
Do not trust a backup because the job reported success or because a checksum matches. Restore it into a clean environment. Open the service. Inspect important data. Verify media, permissions, configuration, and application behavior. Measure the actual recovery point and recovery time. Every missing assumption becomes work to fix.
Then remove the original disposable environment and rebuild it again. This tests something a simple restore does not: whether the project can recreate the surrounding system, recover account and network configuration, handle new machine identity, and follow documentation without relying on the old server.
Finally, migrate it. Prepare another destination first, decide how state and writes will move, test the destination before public cutover, change only the necessary DNS records, verify from outside the server, and keep a rollback path that accounts for any writes accepted during the transition. Changing DNS back is not enough if the new system has already collected state the old system does not have.
Restore tests recovery. Rebuilds test reproducibility. Migrations test portability. Together they provide much stronger evidence than “the server is up.”
Portability is evidence. If you know how to leave, a provider is a dependency rather than a trap.
Distinguish backup, archive, snapshot, replica, mirror, and migration
Create an application-consistent recovery set containing every necessary component
Place recovery copies and recovery keys on failure domains that do not disappear together
Keep enough recovery history to survive corruption or deletion discovered later
Restore into a clean environment and measure actual recovery point and recovery time
LEARN
A backup is useful because it can be restored, not because a file with the word backup exists somewhere.
Different copies solve different problems. A provider snapshot is convenient for rolling a VM back, but it can disappear with the provider account. A replica can improve availability, but corruption, deletion, or ransomware can replicate too. A public mirror preserves public material but normally lacks private data, server configuration, database state, and credentials. An archive preserves material for long-term access. A migration copy is prepared to move a service. These roles can overlap, but none should be silently treated as equivalent.
A recovery set must contain everything needed to reconstruct the capability you care about. For a typical application that can mean database dump, uploaded/user files, application or source code, configuration, dependency/version information, DNS records, documentation, and a secure route to required secrets. For WordPress specifically, the official documentation is explicit that a full backup normally requires both the database and files. The database contains content and settings; the filesystem contains themes, plugins, uploads, configuration, and other material.
Stateful applications need a consistent backup method. Copying a database's live storage files while the database is actively changing is not generally equivalent to using the database's supported backup or dump mechanism. Use the application's or database's documented backup method, and if necessary use a short write pause, snapshot procedure, or other consistency mechanism so the components in the recovery set describe a state that can actually be restored together.
Independence matters more than counting files. The familiar 3-2-1 rule is a useful mnemonic, not a law: multiple copies, different storage or failure domains, and at least one off-site/off-provider copy. The important property is that one disk failure, account closure, theft, ransomware event, cloud-provider mistake, or administrator error does not destroy every recoverable version at once.
History matters too. A backup system that continually overwrites its only previous copy may be useless when corruption or deletion is discovered days later. Choose retention that fits the threat and RPO: enough restore points to go back before likely delayed failures, balanced against storage cost and the sensitivity of old data.
Backups may contain more sensitive information than the public service because they aggregate databases, configuration, private files, tokens, and credentials. Encrypt sensitive backup material at rest, restrict access, and make sure an authorized successor can recover the decryption material without depending on the same lost device or account. A checksum stored separately can help detect accidental corruption. It is not, by itself, proof against malicious modification and it does not prove the application can be restored.
RPO and RTO become measurable here. The actual recovery point is the newest backup you can successfully restore, not the time a job was supposed to run. The actual recovery time includes obtaining authorized access, provisioning the replacement environment, restoring data and configuration, and verifying the service. A timed restore test gives you evidence instead of optimistic scheduling.
DO
Define exactly what this backup must recover. Record an RPO, an RTO, and a retention goal: how much recent work may be lost, how long recovery may take, and how far back you need to be able to restore if a problem is discovered late.
Inventory every component of the disposable service. For a stateful application, use the application's or database's supported backup/export mechanism rather than blindly copying live database storage. Record when the backup was taken and whether writes were paused or otherwise made consistent.
Create a small manifest beside the recovery set containing the backup time, software and operating-system versions, components included, expected restore order, DNS information, and documentation required for recovery. Keep actual passwords, private keys, tokens, and recovery codes out of ordinary documentation; record where authorized recovery material is held instead.
Store the recovery set outside the disposable machine and outside the same provider account or administrative failure domain. Keep another independent copy when the consequences justify it. If the backup contains private data or credentials, encrypt it and prove that an authorized successor can obtain the decryption material through the documented recovery path.
For large or important artifacts, record a checksum in a separately preserved manifest and verify that the copied files match it. This is an integrity check for accidental damage, not the restore test.
Create a clean disposable environment and restore from the independent copy, not from a snapshot still attached to the original machine. Start the timer from the point where you have only the documented access and recovery set. Verify the service externally, inspect representative data and media, check permissions and configuration, and record the newest successfully restored data timestamp. Compare the measured RPO/RTO with the targets.
Keep more than one recovery point where your threat model requires it. Then compare a public mirror/export with the recovery set and list what the public copy would preserve if administrative access vanished and what it cannot preserve.
TEST
Can you restore the service from an independent, application-consistent recovery point that survives loss of the original machine/provider, identify exactly what point in time was recovered, and compare the measured recovery time with the RPO/RTO and retention targets you wrote down?
TEACH
Give another authorized person the independent recovery set, manifest, and documentation in a clean environment. Do not coach them through information that is missing. Every question that requires hidden knowledge, unavailable key material, or an undocumented ordering dependency becomes a defect in the recovery procedure.
Recovery scope, RPO, RTO, and retention targets recorded
Stateful data captured with a supported consistency method
Application/source, data, user files, configuration, versions, DNS, and documentation covered as applicable
At least one independent off-machine/off-provider failure-domain copy exists
More than one recovery point retained where delayed corruption/deletion is in scope
Sensitive backup material and decryption/recovery access protected and survivable
Backup artifacts checked for readability/integrity
Clean-environment restore completed and timed from documented access
Recovered data point and external service behavior verified
Backup, archive, mirror, replica, snapshot, and migration roles are not being confused
Resources
WordPress backups Official example showing why a typical WordPress recovery set needs both the database and files.
Prove recovery does not depend on the original machine or its attached snapshots
Expose undocumented versions, paths, credentials, network settings, and provider assumptions
Handle the new machine's identity and access paths deliberately
Make the rebuild procedure usable by somebody other than its author
Measure recovery from destruction to externally verified service
LEARN
A restore test proves that a copy can recover data. A destroy-and-rebuild exercise tests something broader: whether the surrounding capability can be reproduced after the original environment is gone.
Only do this to an environment whose loss is acceptable. Positively identify the target before any destructive action: hostname, provider/project, instance identifier, IP addresses, attached volumes, and the test data you expect to lose. If the environment contains unique data or a production dependency, it is not disposable and the exercise stops.
A reproducible rebuild does not have to produce a byte-for-byte identical machine. It has to recover the required capability from a known starting environment using an independent recovery set and documented procedure. Record operating-system and important software versions because installing “whatever is current” later can change behavior.
Machine identity can change during a rebuild. A replacement SSH server normally has new host keys, so reconnecting to the same hostname or address may correctly trigger the changed-host-key warning from Lesson 3. Verify the new fingerprint through the provider console or another trusted path before replacing the old known_hosts entry. Do not defeat the warning merely because you expected a rebuild.
Other machine-specific material may also need to be recreated rather than copied blindly: service credentials, TLS state, firewall rules, provider metadata, scheduled jobs, and monitoring registration. The recovery procedure should say which identities are restored, which are regenerated, and where updated values must be recorded.
Verification matters because “the install command exited successfully” proves very little. The rebuilt service should pass the same externally observable checks as the original: DNS where applicable, HTTPS, content/data, media, authentication, permissions, logs, scheduled behavior, and any health checks that matter.
Time is evidence. If recovery requires locating one person's laptop, guessing a package version, or rediscovering a provider setting, the project has found a real dependency even if the server eventually comes back.
DO
Write a destruction scope statement before touching anything: the exact disposable instance or machine, provider/project, identifiers and addresses, attached storage, expected data loss, independent recovery set, and the evidence that production is not involved.
Confirm that Lesson 6 produced a successful restore from an independent copy. A filename that has never restored is not enough to justify destroying the original lab.
Record the current service's acceptance criteria: hostname or test address, expected page or application behavior, representative data/media, authentication behavior, and relevant health checks. Record important software and operating-system versions.
Delete, reprovision, or otherwise recreate only the identified disposable environment. Prefer the provider or virtualization controls that clearly name the target rather than practicing clever destructive shell commands. Start the recovery timer when the original environment is gone.
Rebuild from the documented starting point and independent recovery set. If a hostname or IP is reused and SSH reports a changed host key, stop and verify the replacement machine's fingerprint through the trusted console before updating known_hosts. Record every missing package, version, path, permission, account, firewall rule, DNS step, secret location, scheduled job, or provider setting the instructions failed to mention.
Give the procedure to a second authorized person if possible. Let them perform the rebuild without the original administrator taking over. Questions are evidence.
Run the acceptance checks from another device or network. Verify the same capability, not merely a running process. Update the documentation, then repeat enough of the process in another clean disposable environment to demonstrate that the corrected procedure is sufficient. Record the elapsed recovery time and compare it with the RTO from Lesson 6.
TEST
Can another authorized person recreate the disposable service after the original machine is gone, correctly handle the replacement machine's identity, pass the same external acceptance checks, and meet or explain the difference from the recovery-time target?
TEACH
The second operator is the test. Let them work from the recovery procedure and trusted access paths. If they cannot safely identify the target, verify the replacement host, locate required recovery material, or complete a step, repair the procedure instead of silently supplying the missing knowledge.
Disposable target, project, addresses, and attached storage positively identified before destruction
Independent recovery set had already passed a restore test
Starting OS/software versions and external acceptance criteria recorded
Original environment actually removed or recreated rather than merely repaired
Replacement SSH host identity verified before known_hosts was changed
Missing provider, package, permission, credential, network, and scheduling assumptions documented
External acceptance checks passed after rebuild
Second authorized person can follow the documented process
Measured destruction-to-verification recovery time recorded and compared with RTO
Resources
OpenSSH manual pages Reference for host-key verification and known-host behavior revisited during a rebuild.
Prepare and verify a destination before public cutover
Move state without silently losing or forking writes
Test the final hostname and address path without disabling TLS verification
Change only intended web DNS records while preserving mail and unrelated services
Define rollback criteria and reconcile writes before the migration begins
LEARN
Portability becomes real only when you have moved something. A provider-independent service is one whose data, configuration, names, recovery material, and operational knowledge can be transferred without starting from zero.
Separate migration into preparation, synchronization, cutover, verification, and rollback. The destination should be built before public DNS changes. Restore or deploy there, verify its data and behavior, and know how the final hostname will obtain a valid certificate. A domain-registration transfer is not required merely because hosting is changing.
Stateful services need an explicit write strategy. If users keep posting to the old service while its database is copied, the old and new systems diverge. Options include a maintenance or read-only window, a final synchronization step, database replication designed for the application, or an application-specific migration tool. The correct choice depends on the application. “We copied it while people were still writing” is not synchronization.
Test the destination as the final hostname where practical before cutover. A temporary hostname is one option. Another is controlled client-side resolution such as curl --resolve final.example.org:443:NEW_IP https://final.example.org/ once the destination has a certificate valid for that final hostname. This changes resolution for that client request while preserving the Host/SNI name and normal certificate verification. Do not add -k merely to make a broken TLS setup look successful. If the final certificate cannot exist before DNS cutover under the chosen challenge method, use a temporary hostname or an intentionally configured DNS-validation method instead.
DNS changes do not need to disturb the rest of the domain. Preserve the complete zone first. Web migrations usually change A, AAAA, or CNAME records for web hostnames. MX, mail-authentication TXT records, verification records, CAA, and unrelated hostnames remain unless the migration intentionally includes them. CAA can matter to certificate issuance if the destination uses a different certificate authority.
Lowering TTL can reduce how long newly fetched answers are cached, but it does not rewrite answers already cached under the previous longer TTL. Some resolvers can also serve stale data during failures. During cutover, assume some clients may reach the old destination while others reach the new one. Keeping both sides able to respond safely for a transition period is stronger than assuming a universal switch occurs at one moment.
Rollback must include data, not just DNS. Define conditions in advance: failed HTTPS, missing data/media, broken authentication, unacceptable application errors, background jobs failing, or unexpected impact to mail or another service. If the new service accepts writes after cutover, simply pointing DNS back can strand those writes on the new system. Decide whether rollback requires a write freeze, reverse synchronization, or another reconciliation step before you begin.
DO
Export or record the complete current DNS zone and identify exactly which records the web migration should change. Include A, AAAA, CNAME, MX, TXT, CAA, and any other records present. Confirm that this is a hosting migration, not an accidental registrar or nameserver migration.
Record current TTL values. If you plan to lower a web-record TTL, do it early enough that the previous TTL can age out before cutover. Record the time at which that condition should be true rather than saying “DNS has propagated.”
Build the destination and restore or deploy the service before changing public DNS. Verify data, media, authentication, redirects, permissions, logs, storage, scheduled/background jobs, and any webhooks or external integrations the service actually uses.
Test the destination through a temporary hostname or controlled local resolution. If the destination already has a certificate valid for the final hostname, a command such as curl --resolve final.example.org:443:NEW_IP https://final.example.org/ can exercise the new endpoint while preserving the final hostname and certificate verification. Do not disable TLS verification to make this step pass.
Choose and document the state strategy: maintenance/read-only window, final dump/synchronization, replication, or application-specific migration. Write the exact point when writes stop on the old service, how the final state arrives at the destination, when writes may begin on the new service, and what must happen to new writes if rollback is required.
Prepare the final hostname and certificate path. At cutover, change only the intended web A/AAAA/CNAME records. Check the authoritative answer directly and compare recursive answers. Test IPv4 and IPv6 separately when both are published, then verify HTTPS and application behavior from a network that is not the server itself.
Keep the old environment intact and, where possible, able to answer safely while caches age out. Monitor the new service's logs and externally visible behavior. If a rollback condition occurs, first protect or reconcile writes that exist only on the new system, then restore the saved application state and DNS records. Continue to expect some split traffic until cached answers age out.
Finish by recording actual cutover time, any period of split traffic, failures encountered, whether rollback was exercised, and the point at which the old environment can safely be retired.
TEST
Can you move the disposable service to a different host, preserve state and unrelated DNS services, test the final hostname without bypassing TLS verification, verify both address families externally where published, and execute a rollback procedure that does not silently discard writes created after cutover?
TEACH
Before cutover, have another administrator narrate preparation, pre-cutover testing, write freeze or synchronization, DNS changes, external verification, split-traffic expectations, rollback triggers, and write reconciliation. If they cannot explain what happens to data created after cutover, the rollback plan is incomplete.
Complete DNS zone and existing TTL values preserved
Hosting migration distinguished from registrar/nameserver changes
Destination built and application state verified before public cutover
Final-hostname path tested without disabling TLS verification where possible
Stateful-write and rollback-reconciliation strategy documented
Only intended web DNS records changed
Authoritative and recursive DNS answers checked
IPv4 and IPv6 verified separately where both are published
HTTPS, application behavior, jobs, and relevant integrations verified externally
Old environment retained through transition and rollback conditions written in advance
Actual cutover, split-traffic period, and retirement decision documented
Resources
WordPress migration guidance Concrete official example of moving files/database and handling URL changes safely.
Technical decentralization can conceal social centralization.
A project can operate many servers and still depend completely on one person. That person may hold the registrar account, the only organization-owner role, root access, backup decryption material, billing control, deployment knowledge, or simply the undocumented memory of why the system was built the way it was. Ten machines do not create resilience if one human disappearance removes the ability to operate all ten.
The problem is not that people are unreliable. People have lives, changing capacities, conflicting responsibilities, illnesses, burned-out phones, lost devices, vacations, conflicts, and the right to leave. Infrastructure should be designed around that ordinary reality rather than requiring permanent availability from particular individuals.
Use individual administrative identities wherever systems support them. Individual identities make access review, attribution, selective revocation, and offboarding possible. For SSH, each administrator should use their own key rather than copying one private key between people. For hosting, repositories, DNS, and other control panels, prefer separate accounts and role assignments over one shared owner login.
Authentication redundancy is not the same thing as sharing authenticators. Strong multi-factor authentication or passkeys protect individual accounts, but an organization should not become dependent on one person's phone, security key, email address, or personal recovery codes. Each administrator should have a survivable recovery method for their own identity. Organizational continuity should come primarily from multiple authorized identities and documented transfer/recovery procedures, not from everyone possessing the recovery secrets for somebody else's personal account.
Distribute access according to role. The person publishing articles may not need server-root access. The person maintaining the web server may not need billing ownership. The person paying an invoice may not need the ability to change DNS. Least privilege reduces the impact of compromise and makes responsibilities legible. Redundancy does not require giving everybody maximum privilege; it requires making sure every critical capability has an intentional successor or alternate path.
Some systems still force awkward concentration: one registrant contact, one billing owner, one primary account, or one recovery address. Treat those constraints as named dependencies. Use organizational rather than disposable personal contact points where appropriate, document how control is transferred, and make sure another authorized person knows the procedure before an emergency.
Then distribute knowledge. Two people with administrator accounts are not redundant if only one knows how restoration works. Documentation, pairing, teach-backs, recovery drills, and periodic role rotation create overlapping understanding without pretending everybody must become equally expert at everything.
Service accounts, bots, deploy keys, and API tokens need ownership too. They should not become immortal credentials nobody remembers creating. Record what uses them, what privilege they have, who is responsible for them, where their secrets are stored, and what happens when the human maintainer leaves.
A useful test is temporary disappearance. Choose one administrator and assume they are unreachable. Can the remaining authorized people renew or transfer the domain, reach DNS, access hosting, locate the repository, restore a backup, recover required secrets through the authorized process, and understand the first response to an outage? Every point where the answer is no identifies a real dependency.
The objective is not to eliminate specialization. Specialized knowledge is useful. The objective is to keep specialization from becoming captivity for either the project or the specialist.
Replace routine shared administrator credentials with individual identities where systems support them
Distribute critical access and account-recovery capability without distributing everybody's personal recovery secrets
Apply least privilege while preserving deliberate succession for critical roles
Inventory human accounts, service accounts, SSH keys, tokens, billing control, and recovery dependencies
Create repeatable access-review, disappearance-drill, and offboarding procedures
LEARN
Technical redundancy does not help much if every path still ends at one person's identity.
Individual administrator identities create useful boundaries. They let a project answer who has access, what each person can do, and which access can be revoked when a role changes. Where providers support multiple administrators, give maintainers their own identities. For SSH, install each person's public key separately so one person's access can be removed without replacing everybody's private key. For repositories, DNS, hosting, storage, and monitoring, use provider roles or teams rather than one shared human login where possible.
Least privilege means giving an identity the minimum authorization it needs for its assigned work. It does not mean creating a system so tightly restricted that no authorized successor can recover it. Separate routine privileges from continuity requirements. A publisher may need CMS access but not DNS. A server maintainer may need deployment and host access but not organizational billing. At the same time, a critical capability such as transferring a domain or restoring backup keys should not terminate at one irreplaceable person.
Multi-factor authentication and passkeys strengthen individual accounts, but recovery is part of the authentication design. If an administrator's only authenticator is lost and all recovery methods were on the same device, that account may be unrecoverable. Each administrator should configure and protect the recovery methods their provider supports. Do not solve organizational succession by casually sharing one person's personal recovery codes. Prefer multiple separately recoverable administrator identities, and use explicitly documented break-glass or shared emergency material only when the platform or threat model actually requires it.
Platforms differ. Some offer granular roles and several owners; others still concentrate billing, registrant status, or recovery in one account. Record those constraints rather than assuming “two admins” means every critical action is redundant. For each critical control, identify who can perform the action today and who can take over if that person disappears.
Non-human identities belong on the same map. Deployment tokens, API keys, bot accounts, service accounts, OAuth applications, and deploy keys can outlive the people who created them. Record their purpose, scope, storage location, owner, expiration or rotation expectations, and removal procedure. A forgotten token with broad privilege is still an administrator, just one that never sleeps or attends meetings.
Access reviews should be periodic and event-driven. Review when somebody joins, changes role, leaves, loses a device, or after a security incident. Remove obsolete access rather than only adding new access forever. Rotate shared secrets when somebody who knew them should no longer know them; do not rotate unrelated individual credentials merely for ceremony.
Knowledge needs the same redundancy as credentials. Two people having root access is not useful if only one understands the backup system. Pair access distribution with documentation, teach-backs, and the recovery drills already used elsewhere in this course.
DO
Build an access roster from the dependency map in Lesson 1. Include registrar/registration control, authoritative DNS, hosting, servers, source repositories, deployment systems, backup storage, password or secret-management systems, identity providers, monitoring, billing/payment, and any critical third-party API.
For each surface, record: human or service identity; role/privilege; purpose; recovery path; who can revoke or transfer it; whether another authorized identity can perform the critical action; and the date it was last reviewed. Do not put passwords, private keys, recovery codes, or token values in the roster.
Replace shared routine human accounts with individual accounts where the service supports them. For SSH, confirm each administrator uses a distinct public key and that removing one key would not remove everybody's access. Where a platform supports granular roles, assign the smallest role that permits the required work rather than making every maintainer an owner.
Review authentication recovery. Each administrator should have a protected recovery path for their own account using the provider's supported mechanisms. For critical platforms, confirm that loss of one person's phone, security key, email inbox, or passkey does not remove the organization's only administrative path. If a system truly requires a shared break-glass credential, document when it may be used, how access to it is controlled, and how use is reviewed afterward.
Inventory non-human access: API tokens, deploy keys, service accounts, bots, CI credentials, webhooks with secrets, and unattended backup credentials. Record what each one can do and who is responsible for revoking or rotating it.
Create an offboarding checklist. It should remove the person's provider roles, repository access, SSH keys, active sessions where supported, personal API tokens or app grants, and access to shared secret stores; transfer any organizational ownership or billing responsibilities; rotate shared secrets the departing person knew where appropriate; and preserve non-secret operational documentation.
Run a read-only disappearance drill. Pick one current administrator and assume they and their devices are unreachable. Do not use their accounts, private keys, recovery methods, or inboxes. Another authorized maintainer should locate every critical control, verify they can authenticate through their own identity, locate the latest tested backup and its authorized recovery path, and narrate the first actions for a domain, hosting, or restore emergency. Record every point where the organization still depends on the absent person.
Set a date for the next access review. Access that is never reviewed tends to become archaeology.
TEST
Can the project lose any one administrator and still retain authorized control of the domain, DNS, hosting, repository/deployment path, backup recovery, billing or ownership actions that matter, and the knowledge needed to use them, without borrowing that person's personal credentials or recovery methods?
TEACH
Run the disappearance drill with the least experienced authorized maintainer. Have them use the roster and documentation rather than verbal hints. Every critical action they cannot locate, authenticate to, or explain is a specific access, recovery, or documentation dependency to repair.
Critical administrative surfaces, human identities, and service identities are inventoried
Routine human administration uses individual accounts and individual SSH keys where supported
Privileges are role-appropriate rather than universally maximal
Each administrator has a protected recovery method for their own identity
Critical organizational control does not depend on one person's device or personal recovery codes
Single-owner, registrant, billing, or provider constraints are explicitly documented
API tokens, service accounts, deploy keys, and automation credentials have named ownership and scope
Offboarding includes selective revocation, ownership transfer, and shared-secret rotation where appropriate
One-administrator disappearance drill completed without using the absent person's accounts or devices
Next periodic access review is scheduled or documented
Publication systems are temporary. Published work should be designed to outlive them.
A website is a delivery system, not automatically an archive. A social-media account is a distribution channel, not an archive. A CMS database is operational state, not sufficient preservation by itself. A static mirror is useful, but it is still only one representation of what happened to be publicly reachable.
Preservation starts with the source. Keep writing, original images, audio masters, video source files, transcripts, captions, artwork, authorship, publication dates, identifiers, licenses where relevant, descriptive metadata, and feed information somewhere that does not depend entirely on the production publishing system. Preserve enough context that another person can identify, understand, and republish the material later.
The preservation bundle should also explain itself. A future maintainer should not have to infer which file is the audio master, which image belongs to which article, or whether a timestamp is an upload date or publication date. A small manifest or structured metadata file can record titles, canonical URLs, authorship, dates, relationships, filenames, formats, and checksums for important artifacts.
For public material, static mirrors add another kind of survivability. If a production site disappears, a static copy can preserve readable pages and public files without reproducing the original CMS. If administrative access is lost while the public site remains reachable, a mirror can sometimes preserve what is still exposed before it disappears.
But a mirror has strict limits. It normally cannot recover private drafts, accounts, server configuration, database-only relationships, unlinked originals, private media, or interactive server-side behavior. JavaScript-heavy applications may expose only a fraction of their meaningful state to a conventional crawler. Search, comments, forms, authentication, APIs, pagination, generated feeds, and streaming behavior may need separate preservation. Third-party assets may remain on third-party systems unless they are deliberately and lawfully captured.
That is why the course separates backup from preservation. A recovery backup is meant to restore a working system or its data. A source archive preserves original material and context independently of a presentation system. A static mirror preserves a useful public representation. A web-archive format such as WARC can preserve HTTP retrieval records and responses for archival tooling. None is automatically a substitute for the others.
Verification matters here too. A successful crawler exit code is not enough. Make the live origin unavailable to your test environment and browse the copy locally. Open PDFs. Play audio. Check images and styles. Follow internal links. Search the downloaded material for references to the production hostname and external domains. Record what no longer functions and what still depends on something outside the preservation set.
Then try to reconstruct one published piece using only the preservation bundle. If you cannot identify its title, date, author, text, media, captions or transcript where applicable, and the relationship between those files without opening the production CMS, the preservation set is incomplete.
Publishing for disappearance means preserving meaning, material, and enough structure to make the work useful after the current interface is gone.
Distinguish source preservation, a public static mirror, a web-archive capture, and a recovery backup
Preserve original material, relationships, and descriptive metadata independently of the production CMS
Create a bounded, polite static copy of an authorized public site
Verify the mirror without relying on the live origin or unnoticed third-party dependencies
Document dynamic, private, generated, or external capabilities a static mirror cannot preserve
Reconstruct a representative published item from the preservation bundle alone
LEARN
Publication and preservation are different jobs. A production CMS is optimized for creating and serving current material. Preservation is concerned with whether the work remains intelligible and usable after that system changes or disappears.
Preserve source material separately from the presentation layer. For text, keep editable source where possible, exported/public output, attachments, and metadata needed to reconstruct titles, authors, dates, canonical URLs, and relationships. For audio, keep masters, distribution copies, artwork, metadata, transcripts, and feed information. For video, keep high-quality source, captions, artwork or thumbnails where useful, metadata, and distribution copies. A public HTML page without its original media, attribution, or contextual metadata can be a poor archive even when it still renders.
Add a small preservation manifest. It can be human-readable text, CSV, JSON, or another durable format appropriate to the project. Record enough information to connect source files to published items: title, author or collective attribution, publication date, original URL or identifier, media filenames, transcript/caption filenames, format information, and checksums for important artifacts where useful. Do not make the manifest depend on a proprietary application just to be readable.
If administrative access is gone but an authorized public site is still reachable, a crawler such as GNU Wget can sometimes preserve the public surface. That is not equivalent to a backup. It cannot recover data that was never public, and ordinary recursive crawling does not execute a modern application like a human browser. Client-rendered content, API state, private drafts, server configuration, user accounts, unlinked originals, comments, forms, search, or streaming systems may be absent.
GNU Wget's --mirror enables a group of recursive mirroring options including recursion and timestamping. --convert-links rewrites suitable links for local viewing, --adjust-extension gives HTML responses useful local filename extensions, and --page-requisites retrieves assets needed to display downloaded HTML pages. --no-parent prevents recursive traversal above the starting path. Wget does not recursively span arbitrary hosts unless told to do so; this is useful because a site that depends on a CDN, embed host, or third-party media service may otherwise leave external dependencies in the mirror.
Recursive retrieval can consume substantial bandwidth, disk space, and server resources. GNU Wget honors robot-exclusion rules during recursive retrieval by default. For this exercise, use only public material you control or are explicitly authorized to preserve, keep the starting path narrow, use pacing such as --wait=1, and stop if the target shows distress or rate-limit errors. Do not introduce authenticated sessions or attempt to crawl private areas just to make the mirror “complete.”
Wget can also write WARC files with --warc-file. A WARC can be useful as an additional archival artifact because it records retrieved web resources in a standardized container used by web-archiving tools. It is not a replacement for the editable source bundle, and a WARC is not necessarily the most convenient artifact for a human who simply needs to open the publication tomorrow.
Verification therefore has to happen with the live origin unavailable. Test both representative pages and representative media. A static copy that secretly fetches critical CSS, JavaScript, images, fonts, audio, or documents from the production site is still dependent on that site.
DO
Choose one representative published item. Gather its editable source where available, original or highest-quality media you retain, title, authorship or collective attribution, publication date, canonical URL or identifier, captions/transcript where applicable, artwork, and any feed metadata needed to publish it elsewhere.
Create a small manifest for that item. Record the filenames and their roles so another person can understand the bundle without the CMS. Add checksums for large or important source artifacts if that helps you detect accidental corruption later. Store the preservation bundle independently of the production CMS and its hosting account.
Choose a harmless public site or subdirectory you control or are explicitly authorized to preserve. Start from the narrowest useful path. A reasonable conventional-site exercise is:
Substitute the authorized target. Read the Wget output. If the target begins returning rate-limit or server errors, stop rather than “fixing” the crawler by making it more aggressive. Remember that --no-parent constrains the path hierarchy; it does not magically make a dynamic application complete.
If important display assets live on another host you also control or are authorized to archive, first identify that dependency explicitly. Do not casually add unrestricted host-spanning recursion. Either preserve those assets separately, or if you deliberately use Wget host-spanning options, limit the allowed domains to the specific authorized hosts and record that choice in the preservation notes.
Optionally, make a second archival capture using Wget's WARC support if WARC fits the project's preservation plan. Keep the browsable mirror and source bundle regardless; each artifact solves a different problem.
Now verify independence. Disconnect the test machine from the network or block the production and external hosts it would otherwise reach. Because file:// behavior can differ from an actual web origin, serve the downloaded mirror from a disposable local-only HTTP server when necessary and browse it through localhost. Follow representative internal links and open images, stylesheets, PDFs, audio, video, and feeds that matter.
Search the downloaded text for the production hostname and known third-party hostnames. Classify each remaining reference: harmless attribution/canonical link, intentionally external resource, or dependency that prevents the mirror from functioning independently.
Write a limitations list: missing client-rendered content, forms, search, comments, API-driven pages, pagination, external embeds, streaming media, authentication, or anything else that did not survive as static material.
Finally, using only the independent source/preservation bundle, reconstruct the representative item in another disposable publishing environment. Compare this with restoring the recovery backup from Lesson 6. Record what the backup can restore that preservation cannot, and what the source/mirror archive can preserve even when the original application is no longer recoverable.
TEST
Can you make the live origin unavailable, browse the important preserved public material locally, identify every important dependency or capability the static mirror did not preserve, and reconstruct a representative item from independently stored source, media, and metadata?
TEACH
Give another person the source bundle, manifest, static mirror, and any optional WARC without access to the production CMS. Ask them to identify what each artifact is for, reconstruct the representative item, and explain which missing capabilities require a running application or database rather than a static copy.
Editable/source material and important original media preserved independently
Authorship, dates, identifiers/URLs, relationships, captions/transcripts, and feed metadata preserved as applicable
Preservation manifest explains the files without requiring the production CMS
Mirror created only from an authorized public target with bounded scope and request pacing
Robot exclusion and crawler-load behavior understood rather than silently bypassed
Cross-host dependencies identified and host-spanning retrieval not enabled without explicit bounded authorization
Mirror tested with the live origin and important external dependencies unavailable
Images, styles, documents, media, and representative internal links verified locally
The public internet is the dominant network people use every day, but it is not the only possible relationship between computers.
Most people encounter networking through a familiar stack: an application uses a name, DNS may translate that name into addresses, IP routing chooses a path toward an address, a transport protocol carries traffic, and an application listens or sends on top of that transport. This course teaches that model first because it underlies most of the infrastructure people currently depend on.
A local network makes those layers easier to see. A device has interfaces. Interfaces can have several addresses and address scopes. Routes determine which destinations are directly reachable and which require a router. A default route is the fallback used when no more specific route matches. DNS supplies names, but two machines do not need DNS in order to communicate by address.
IPv4 and IPv6 need to be examined separately. Common home IPv4 networks use private RFC 1918 addresses and often use NAT when reaching the public internet. IPv6 does not imply one universal kind of address: an interface may have link-local addresses, Unique Local Addresses intended for limited networks, globally routed addresses, or several of these at the same time. A globally scoped IPv6 address also does not mean an inbound service is necessarily reachable; routing and firewall policy still decide that. NAT and firewalling are different mechanisms.
“On the same Wi-Fi” does not always mean “able to talk directly.” Guest networks, VLANs, wireless client isolation, host firewalls, and routing policy can separate devices that appear physically close. The network you actually have matters more than the label on the access point.
Once you understand the conventional stack, alternative network systems become easier to evaluate without mystifying them. Reticulum, for example, exposes application endpoints as destinations represented by 128-bit hashes derived from destination identifying information. It can use many different underlying interface types. Its AutoInterface can discover nearby peers over Ethernet or Wi-Fi using IPv6 link-local functionality and UDP transport without requiring ordinary router or DHCP infrastructure.
That different abstraction does not abolish the underlying world. Reticulum still runs over physical or virtual interfaces with finite bandwidth, firewall behavior, link conditions, software, endpoints, and operators. Other Reticulum interfaces can themselves run over conventional IP networks. An alternative addressing or routing model does not automatically provide anonymity, endpoint security, safe applications, or protection from transport metadata.
The practical purpose of this section is to make networking less rigid in your head. First run and troubleshoot something on a LAN while observing address scope, routes, listeners, and firewalls. Then inspect a different network abstraction and ask what it changes, what it hides, and what still exists underneath.
A network becomes useful to a community when more than one person can operate and explain it. That returns the technical exercise to the course's central theme: capability has to move between people.
Identify interfaces, IPv4 and IPv6 address scopes, directly connected networks, routes, and default gateways
Distinguish a service bound to loopback, a LAN address, or a broadly reachable interface
Distinguish local reachability, routed reachability, NAT, firewall policy, and DNS
Test IPv4 and IPv6 as separate network paths
Troubleshoot from the nearest observable layer outward without changing unrelated systems
LEARN
A local network is a good place to learn because you can make the boundaries visible without deliberately publishing a service to the public internet.
An interface can have several addresses. In common IPv4 home networks, the RFC 1918 ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are intended for private internets and are not globally routed as public addresses. A router commonly translates private IPv4 traffic with NAT when it leaves the local network. NAT is not the same thing as a firewall and should not be treated as the security policy.
IPv6 has multiple scopes and purposes. A fe80::/10 link-local address is intended for communication on the local link. Unique Local Addresses in fc00::/7 are intended for local or limited-site communication and are not expected to be routed on the global internet. A device may also have globally scoped IPv6 addresses. Inspect the actual address and route rather than reducing IPv6 to “public” or “private.”
Routes decide where packets go. Traffic to a directly connected subnet does not normally need to pass through the default gateway. The default route is the fallback for destinations that do not match a more specific route. On local Ethernet and Wi-Fi, the system also needs a way to discover the link-layer neighbor associated with a local destination; IPv4 commonly uses ARP and IPv6 uses Neighbor Discovery. You do not need to memorize those protocols yet, but understanding that local delivery still requires link-layer discovery explains why “the IP looks right” is not the end of diagnosis.
DNS is a naming layer, not proof that the network path works. If a connection succeeds by address and fails by hostname, investigate name resolution. If it fails by address too, changing DNS is unlikely to repair it.
Binding matters. A service listening only on 127.0.0.1 or ::1 is normally available only on that machine. A service bound to one LAN address is available through that address if routing and firewalls permit it. A wildcard listener can accept traffic arriving on multiple interfaces. Socket state, route state, and firewall state are separate observations.
“Same Wi-Fi” is not a guarantee of peer reachability. Guest isolation, VLANs, access-point client isolation, host firewalls, and different subnets can prevent two devices from talking directly.
On Linux, ip -br addr gives a compact interface/address view, ip route shows IPv4 routes, ip -6 route shows IPv6 routes, and ss -lntup shows listening TCP and UDP sockets when permissions allow process details. Other operating systems have equivalent tools. The important skill is knowing which question each observation answers.
DO
Use a disposable Linux machine, VM, or spare device on a network where you are authorized to experiment. Do not change the router or publish new inbound internet rules for this lesson.
Inspect the machine with ip -br addr, ip route, and ip -6 route. For each interface you care about, record its IPv4 address if present, its IPv6 link-local address, any Unique Local or globally scoped IPv6 address, the directly connected prefixes, and the default routes. Note that an interface can have more than one valid address at once.
Run a simple harmless service bound deliberately to a LAN address rather than a wildcard. If Python is already available, an example is python3 -m http.server 8000 --bind 192.168.1.50, replacing the example address with the machine's actual LAN IPv4 address. Use another simple server if that is more appropriate to the system.
Confirm the listener with ss -lntup or the platform equivalent. On the server itself, request the service using the same LAN address and port. Then, from a second authorized device on the same local network, request that address directly. If it fails, check whether both devices are actually in mutually reachable subnets, whether the service is bound to the intended address, whether a host firewall blocks the port, and whether the Wi-Fi or VLAN configuration isolates clients.
Use the route table to explain the path. On Linux, ip route get CLIENT_IPV4 can show which IPv4 route and interface the server would use toward a particular client. Do the equivalent reasoning for IPv6 if you are testing IPv6.
Inspect public exposure without creating it. For IPv4, check whether the router or upstream platform has an inbound port-forward or other rule for this service. For IPv6, check whether the machine has a globally scoped address and what the host/router firewall permits inbound. Do not open a port merely to demonstrate that a closed port was closed.
Create safe controlled failures one at a time. Stop the service. Restart it bound only to 127.0.0.1 and observe why another LAN device can no longer connect. Try the correct address with the wrong port. If you have local DNS or a hosts-file test you are comfortable reverting, use a deliberately incorrect name separately. For each failure, record which observation distinguished it from the others before changing anything.
Finish with a small diagram showing the client, its address, the server and listening address, the directly connected network, any gateway used for non-local traffic, the relevant firewall boundaries, and where DNS would enter the picture.
TEST
Can you explain which of the machine's addresses are loopback, link-local, private/unique-local, or globally scoped; show which route is used to reach the test client; identify exactly where the service is listening; and diagnose a deliberately introduced failure without changing multiple layers at once?
TEACH
Give another learner a deliberately broken local service and the network diagram without telling them which failure you introduced. Have them state the next observation they want and what competing explanations that observation would distinguish before they change anything.
IPv4 and IPv6 interfaces and address scopes identified
Directly connected prefixes and default routes identified separately
Local service deliberately bound to a known LAN address and port
Listener confirmed with a socket-inspection tool
Second authorized LAN device reached the intended service by address
Client isolation, VLAN/subnet, and host-firewall possibilities considered where relevant
IPv4 NAT/port-forward exposure and IPv6 global-address/firewall exposure checked separately
At least three safe controlled failure modes diagnosed one at a time
Final network diagram distinguishes interfaces, routes, gateway, firewall boundaries, and DNS
Reticulum AutoInterface documentation Useful bridge to Lesson 12: shows how one alternative network uses IPv6 link-local functionality on Ethernet and Wi-Fi.
Recognize that hostname/IP/port assumptions are not the only application-facing network model
Describe Reticulum destinations and interfaces from current project documentation without turning project claims into universal security guarantees
Install Reticulum in a disposable user environment using the documented method for that platform
Inspect the actual Reticulum configuration, interfaces, version, and local discovery prerequisites
Compare Reticulum's application-facing model with the conventional IP/DNS model while identifying what still exists underneath
Teach one complete infrastructure skill to another person and revise the procedure from their failures
LEARN
Alternative networking is useful here because it forces you to separate concepts that ordinary internet use often bundles together. A network application does not have to begin with a globally meaningful DNS name and a client connecting to a fixed IP address and TCP port.
Reticulum is one concrete system to study. Its current documentation represents application endpoints as destinations. Destination addresses are 16-byte (128-bit) hashes derived from a SHA-256 hash of identifying characteristics. For single destinations, identity information contributes to that derivation, allowing different identities to use the same application/aspect names while remaining distinct destinations. Applications can therefore work with destination identities without the application itself treating an IP address as the endpoint identity.
Reticulum still needs interfaces that can carry packets. Those interfaces can use very different underlying media and transports. Some run over conventional TCP/IP links. AutoInterface is particularly useful for this lesson because it can communicate with discoverable Reticulum peers over local Ethernet or Wi-Fi. The current documentation says AutoInterface uses IPv6 for peer discovery and UDP for packet transport, requires link-local IPv6 support on the participating interfaces, and can work on the local link without ordinary DHCP or router infrastructure.
This is an abstraction boundary, not the disappearance of networking. Ethernet, Wi-Fi, radios, operating-system interfaces, firewalls, client isolation, bandwidth, loss, and endpoint security still exist underneath. If Reticulum itself is transported over an internet connection, that underlying IP path still has operators and metadata. Do not infer anonymity, physical security, malware resistance, or protection against every adversary merely from the destination model.
The first Reticulum program launched on a system creates or uses a configuration directory. Current project documentation searches /etc/reticulum, ~/.config/reticulum, and ~/.reticulum, and creates ~/.reticulum with a default configuration when no existing configuration is found. rnstatus shows the configured interfaces and their status. Read the actual configuration before assuming which interfaces are active.
On current Debian and Ubuntu releases where the system Python environment is externally managed, the Reticulum documentation provides a pipx installation path: install pipx from the operating system, run pipx ensurepath, then pipx install rns. pipx installs the application into an isolated environment rather than modifying the system Python package set. Other platforms have different documented installation methods, so follow the current project instructions for the system in front of you.
For local AutoInterface troubleshooting, the current Reticulum documentation identifies link-local IPv6 as a prerequisite and notes that host firewalls or Wi-Fi client isolation can block discovery. It documents UDP ports 29716 and 42671 for the default AutoInterface behavior. That does not mean “turn the firewall off.” It means identify the specific traffic the experiment requires and understand why it is blocked before changing policy.
DO
Read the current Reticulum “Understanding Reticulum,” “Using Reticulum on Your System,” “Building Networks,” and interface documentation before changing anything. Write down three differences between a Reticulum destination and the hostname/IP/port model used earlier in the course, plus three things that still depend on the underlying network or device.
Use a disposable user environment. On a current Debian/Ubuntu system with externally managed system Python, use the documented isolated application route: sudo apt install pipx, then pipx ensurepath, start a new shell if needed, and run pipx install rns. Do not use sudo pip install or modify the system Python environment merely to complete the exercise. On another operating system, use Reticulum's current documented installation method for that platform.
Record the installed version with the utility's version option where available. Run rnstatus and inspect every interface it reports. Locate the configuration directory actually in use. If no system or XDG configuration existed, the default user configuration may be at ~/.reticulum/config; verify rather than assume. Read the file before editing it. You can use rnsd --exampleconfig as a reference without replacing your working configuration.
For the local AutoInterface exercise, inspect the underlying machine first. Confirm the Ethernet or Wi-Fi interface has an IPv6 link-local address, for example with ip -6 addr show scope link on Linux. Do not enable globally scoped discovery or add public backbone interfaces for this exercise.
If you have two disposable devices on the same Ethernet or Wi-Fi segment, install Reticulum on both and inspect rnstatus. Observe whether AutoInterface reports a reachable peer. If it does not, investigate the local link before changing Reticulum at random: verify link-local IPv6 on both devices, check whether the access point isolates wireless clients, and inspect host-firewall handling of the documented AutoInterface UDP traffic. Make only narrow, reversible firewall changes when they are actually required and authorized; do not disable the firewall wholesale.
Read both generated/configured Reticulum interface state and the underlying OS state. Write a comparison table with these columns: application endpoint identity, naming/address allocation, route/path discovery, underlying interface or carrier, firewall/link assumptions, and failure modes. Fill one row for the conventional local IP service from Lesson 11 and one for the Reticulum AutoInterface exercise.
Finally, choose one course skill you can perform reliably. Write a teaching procedure with purpose, prerequisites, steps, expected observations, verification, at least one safe failure, and recovery. Give the procedure to another person. They operate the keyboard or equipment. You may answer clarification questions, but do not silently perform the missing steps for them. Revise the procedure from every place where they needed knowledge that was only in your head.
TEST
Can you explain how a Reticulum destination differs from a hostname/IP/port endpoint, show the Reticulum version, configuration path, and interfaces on your disposable installation, explain why AutoInterface needs the local link conditions it does, and teach another person one complete infrastructure task without taking control of the task?
TEACH
The teach-back is the final practical. The learner should perform the chosen task, state the observations that prove success, encounter or reproduce at least one safe failure, and recover using the written procedure. Update the procedure until the missing knowledge lives in the document rather than in the original operator.
Current Reticulum conceptual and interface documentation read before installation
Destination hash model compared accurately with hostname/IP/port endpoints
Reticulum installed in a disposable user environment with the documented platform method
System Python was not modified merely to bypass externally-managed-environment protections
Installed Reticulum version, configuration path, and rnstatus output recorded
Actual configuration read before interfaces were changed
IPv6 link-local prerequisite for local AutoInterface inspected
Local firewall/client-isolation conditions investigated without broad security controls being disabled
No anonymity or universal security guarantee inferred from the alternative network model
Conventional IP service and Reticulum exercise compared at both application and underlying-link layers
Another person completed one taught infrastructure skill and the procedure was revised from observed failure points
This is not a server guide in the sense that its conclusion is “host everything yourself.”
Self-hosting moves responsibility. It does not eliminate dependency, and it does not automatically increase safety, autonomy, or resilience. A project that replaces a competent managed service with a machine nobody has time to patch has not escaped dependence. It has changed which failures it owns.
Some services carry operational burdens that are easy to underestimate. Email is a strong example. Running a mail system is not merely installing SMTP and creating accounts. Reliable operation can involve DNS authentication such as SPF, DKIM, and DMARC; TLS; queues; storage; spam and abuse handling; sender reputation and deliverability; account recovery; patching; monitoring; backups; restore testing; and incident response. A server successfully sending one test message does not establish that an organization should depend on it for private communications.
Identity systems, databases containing sensitive records, collaborative platforms, payment systems, and services holding legal or personal information raise similar questions. The cost of a failure may include disclosure, irreversible data loss, account takeover, missed communications, or harm to people, not merely an unavailable page.
Autonomy therefore includes the ability to choose a provider deliberately. A managed or shared service can be a reasonable dependency when the project understands who controls the account, can recover access without one irreplaceable person, keeps appropriate independent copies, knows what can be exported and in what format, documents the configuration that matters, and has a believable exit path.
The same standard applies to self-hosting. Ask what happens when the administrator leaves, the machine fails, the hosting account closes, the software needs an urgent security update, the backup does not restore, or the service grows beyond the available time and skill. Running the machine yourself does not make those questions disappear.
Reduce the problem before deciding where to host it. Do not collect information merely because software makes collection easy. Do not retain information longer than the project needs it. Do not add an application when durable static files solve the problem. Do not create administrator accounts, plugins, integrations, analytics, databases, or secrets that provide no necessary capability. Data you never collect cannot later be leaked from your server, trapped in a provider export, or forgotten in an old backup.
Then evaluate the arrangement against the real stakes. How damaging is downtime? How damaging is disclosure? How much recent data can be lost? Who can maintain the system when the primary operator is unavailable? Can the organization export its data in usable forms? Are backups independent and tested? Can the service be rebuilt or migrated? Is the operational labor sustainable? Does the provider or self-hosted design introduce a failure domain the project has accepted consciously?
Sometimes the resulting answer is self-hosting. Sometimes it is infrastructure shared among several organizations. Sometimes it is a cooperative or nonprofit provider. Sometimes it is a commercial managed service with strong recovery and export. Sometimes a hybrid arrangement makes sense: control the domain and source archive, keep independent backups, but pay somebody else to operate the mail system or database. Sometimes the correct answer is to stop running a service whose benefit no longer justifies the data, labor, or risk.
The useful question is not “Can we run this ourselves?” It is “Which arrangement gives this project enough control, safety, recoverability, maintainability, and ability to leave for the consequences that actually matter?”
The command line is the easy part to demonstrate. The harder skill is judgment.
Someone applies updates. Someone reads an alert. Someone notices a disk filling. Someone tests the backup. Someone renews the domain. Someone reviews access. Someone migrates an old application. Someone answers the person who cannot log in. Someone documents what changed. Someone eventually decides that a service should be retired.
Infrastructure therefore has a labor model whether the project acknowledges it or not.
When maintenance is informal, work tends to accumulate around whoever notices failures first, has the most technical confidence, or has historically rescued the system. That person can become both indispensable and exhausted. The project then has two coupled single points of failure: the technical service and the sustainability of the person maintaining it.
Make the labor visible. For every production service, record the recurring work required to keep it trustworthy: operating-system and application updates, security advisories, storage and inode checks, backup jobs, restore tests, certificate renewal, domain renewal, billing, account review, dependency upgrades, log and monitoring review, incident follow-up, documentation changes, and periodic decisions about whether the service should continue to exist at all.
Not every responsibility belongs on a rigid calendar. Separate scheduled work from event-driven work. Domain renewal may have a known date. Access review may happen quarterly and whenever somebody joins, leaves, loses a device, or changes role. Security updates happen when updates are released. Incident review happens after an incident. The maintenance plan should make both kinds of work visible.
Automation changes the labor; it does not erase it. An automated certificate renewal still needs somebody to notice when it fails. An automated backup still needs restore tests. An unattended-upgrade process still needs somebody to understand when a reboot or service restart is required. A monitoring system whose alerts go to an abandoned inbox is not monitoring. Every automation needs an owner, an observable success or failure signal, and a recovery procedure.
Avoid turning monitoring into permanent alarm. An alert should correspond to something a person can meaningfully investigate or act on. If a system emits so many unactionable warnings that maintainers routinely ignore it, the alerting system has created noise rather than resilience.
Make ownership visible without making it singular. A task can have a primary maintainer and at least one second person who can perform it, verify it, or take over. The second person does not need identical expertise, but they need enough access, documentation, and practice that “backup maintainer” means more than a name in a spreadsheet.
Track maintenance debt explicitly. Deferred upgrades, unsupported software, undocumented workarounds, expiring hardware, untested restore paths, and one-person procedures are liabilities even while the service appears healthy. Naming them makes it possible to decide whether to repair, replace, simplify, or retire the system before an emergency makes the decision for you.
Document exceptional knowledge: why a strange configuration exists, what cannot be upgraded casually, which provider limitation shaped a decision, what dependencies must move together, and what rollback procedure was actually tested. Record decisions as well as commands. Future maintainers need to know not only what the system looks like but why it looks that way.
After an outage or near miss, update the operating model. If the incident exposed a missing alert, undocumented credential, impossible recovery target, or task only one person knew how to perform, the corrective action is not complete until the responsibility, documentation, and recovery procedure have changed.
Infrastructure labor belongs in project planning. If nobody has time to maintain a service, that is a design constraint, not a moral failure. The honest options are to simplify it, pay or collaborate for competent maintenance, reduce its scope, or retire it.
Resilient infrastructure is not only infrastructure that survives hardware failure. It is infrastructure whose care can be sustained, observed, transferred, and shared without quietly consuming the person who understands it best.
The objective is not to turn every participant into a full system administrator.
The objective is a web of partial, overlapping knowledge strong enough that no necessary capability disappears with one person.
One person may understand domains and DNS. Another may know Linux administration. Another may understand publishing workflows. Another may be good at backup verification. Another may write excellent documentation. Another may understand local networking or hardware. Another may know the organization's accounts, billing relationships, or data-retention decisions. None of them needs complete mastery for the group to become more capable.
The important question is not whether knowledge is distributed. It is whether critical knowledge overlaps.
Partial knowledge becomes dangerous when it is isolated. If the DNS person cannot explain enough for anybody else to make or verify a safe change, if the backup person is the only person who knows where copies live, or if the publication workflow exists only as muscle memory in one editor's head, the project still has a single point of failure. Documentation, pairing, shared exercises, and teach-backs create overlap.
A useful target is not “everyone knows everything.” It is that every critical capability has more than one route through the group. One person may be able to perform the task directly, another may be able to follow the runbook and verify it, and a third may know when to stop and call for help. Those are different levels of knowledge, and all can contribute to resilience.
Make the knowledge map visible. Alongside the dependency and access maps, record which people can operate, verify, recover, or teach each important capability. This exposes strange asymmetries: five people may have administrator accounts while only one has ever restored a backup; three people may know the CMS while nobody besides the domain holder understands DNS.
Good documentation is part of the network, but “documentation” is not one thing. A future maintainer may need an overview explaining what exists and why; a runbook for routine operations; a recovery procedure for emergencies; and a decision record explaining non-obvious constraints. A transcript of commands with no explanation is difficult to adapt. A conceptual essay with no operational detail is difficult to use during an outage. Useful documentation connects purpose, procedure, verification, and recovery.
Write for the person who was not in the room. Name the service, account, path, expected result, and stopping condition. Explain which steps are safe to repeat, which actions are destructive, which assumptions must be checked first, and how the operator knows the procedure succeeded. Keep secrets out of ordinary documentation while documenting where authorized recovery material is held.
Teaching creates a second form of verification. When another person follows an instruction, they expose hidden assumptions that the author no longer sees. If the learner cannot reproduce the task, the first question should not be whether the learner failed. Ask whether the procedure depended on an unstated path, account, permission, vocabulary term, or piece of historical knowledge.
Projects can overlap with other projects too. A small group does not need to reproduce the expertise of a large hosting collective, network cooperative, or specialist administrator. It can retain enough literacy to describe its problem accurately, understand what the specialist controls, provide useful diagnostics, maintain independent copies, and know how to leave if the relationship stops working. Mutual technical support becomes stronger when neither side has to treat the other as magic.
Knowing when not to proceed is also knowledge. A maintainer who recognizes that a failing disk, corrupted database, compromised credential, or unfamiliar mail system exceeds their current expertise can prevent a difficult problem from becoming a catastrophic one. Escalation should be documented like any other operational path: who can help, what information they need, and what should not be changed before they look.
Review the knowledge map over time. People leave. Systems change. Documentation ages. A task that had three competent operators two years ago may have one today. Overlap has to be maintained, not merely achieved once.
The goal is a community where people know enough to maintain their own dependencies, enough to assist one another, enough to learn from documentation, and enough to recognize when a task requires outside help.
That is a more durable form of decentralization than simply multiplying machines.
There is no single blueprint for autonomous infrastructure, and there should not be one. People have already been doing this work, often without giving it a particularly grand name. They have maintained independent media servers, hosted archives, kept community websites alive, built communication systems, run services from old hardware, recovered from compromises, documented systems for the next person, and taught technical skills to people who did not initially think those skills belonged to them.
Sometimes people learned because they were curious, sometimes because a project needed something done and nobody else knew how, and sometimes because something broke badly enough that there was no other option. Either way, movements have accumulated a tremendous amount of technical knowledge through years of experimentation, improvisation, failure, and mutual aid.
The problem is that much of that knowledge disappears when people leave. A person moves away, burns out, changes projects, loses access to a machine, or simply gets tired of being the person everyone calls whenever something breaks, and suddenly an entire body of practical knowledge can vanish with them. The next group then begins from the same place, relearning the same lessons and making the same mistakes because nobody had the time, habit, or infrastructure to pass those lessons along.
We should not have to rediscover the same knowledge forever.
That means listening to the people who have already built and maintained movement infrastructure and asking what they learned along the way. What broke? What did they wish they had documented? What knowledge disappeared when someone left? What did they have to learn the hard way, and what would they teach differently now? There is no reason every collective should have to begin at the same starting line when people have already spent years figuring out what works, what fails, and what becomes a problem six months after everyone thinks the project is finished.
The point is not to create one standardized model that every movement has to follow. It is to make the accumulated experience of other people available to those who come next.
Ask the question directly:
If your project disappeared tomorrow, what would survive without you?
Would the source code still exist somewhere another authorized person can access? Would published writing and media remain readable? Would the domain be recoverable? Would a tested backup exist outside the provider that disappeared? Would anybody know how to decrypt and restore it? Would important contacts, documentation, decisions, and operational knowledge survive the loss of one person's laptop or account?
The point is not to imagine one spectacular catastrophe. Ordinary failures are enough: an expired payment card, a forgotten renewal, a provider policy change, an inaccessible email account, corrupted storage, a stolen device, an administrator leaving, a project dissolving, a dispute over control, a building losing power, or simply nobody remembering how an old system works.
Resilience is demonstrated by what happens after the loss.
A service that never fails can conceal fragility for years. A project that has repeatedly restored backups, moved providers, rotated administrators, exported its data, reconstructed publications from source, and taught new maintainers has evidence that it can continue when components disappear. Evidence is stronger than confidence.
Not everything should survive in the same way.
Some capabilities deserve continuity: the service should keep operating or be recoverable quickly.
Some material deserves preservation: the live application may disappear while publications, records, source material, or history remain readable.
Some things need transfer: ownership, domains, repositories, archives, or responsibilities should move to another person or organization.
Some things should expire or be deleted: credentials, unnecessary personal data, obsolete account exports, old access, or records the project no longer has a reason to retain.
Those categories should be decided deliberately. “Keep everything forever” is not a resilience strategy. It creates its own security, privacy, storage, governance, and interpretive problems. Likewise, “delete it” is not complete until the project knows which production copies, backups, replicas, exports, archives, and provider retention paths actually contain the material and what deletion is realistically possible in each system.
Make a continuity and disposition inventory. For every important service or dataset, choose an intended outcome: continue, restore, preserve, transfer, or retire/delete. Record the responsible people, authoritative source, independent copies, recovery or export method, approximate retention expectations, and the event that should trigger review.
Then test the answer.
Use disposable systems for technical failure tests and tabletop exercises for organizational failures that cannot safely be simulated. Assume the registrar account holder is unreachable. Assume the hosting provider is gone. Assume the repository is unavailable. Assume the production database is corrupted. Assume the primary administrator's device is seized, destroyed, or simply inaccessible. Assume the project decides to dissolve rather than recover.
For each scenario, ask the same questions: What authoritative copy remains? What independent copy remains? Which authorized identity can act? Which documentation explains the next step? Which person or outside relationship can perform it? What data might be lost? What should not be restored because the correct outcome is preservation or deletion instead?
Do not count inaccessible material as survival. A backup encrypted with a key nobody else can recover is not a usable continuity plan. A repository in a personal account nobody can access is not organizational source control. An archive whose filenames and metadata nobody can interpret has survived physically while losing much of its meaning.
Also test time. If a domain can technically be recovered but only after weeks of account-recovery escalation, that may be acceptable for an archive and unacceptable for an active emergency service. If a publication can be reconstructed eventually but not within the stated RTO, the difference should be visible rather than disguised by the word “backup.”
End-of-life is part of resilience too. A discontinued publication may not need a permanently running CMS; static archives and source material may be enough. A dissolved organization may preserve public history while removing unnecessary private records and revoking access. A retired server should not remain online indefinitely merely because nobody was assigned to turn it off.
The final test is not whether every machine survives.
It is whether the project has decided what deserves to continue, what deserves to remain readable, what must be transferable, what should disappear, and whether another authorized person can carry out those decisions without the people who originally built the system.
Eventually, the server itself stops being the most interesting part of the project. What matters is what happens when the server disappears.
If you know how to rebuild it, the loss is different. If you have documented the process, someone else can rebuild it. If you have taught three people, there are now four people who can do what once depended on one. If those people teach others, the knowledge begins moving farther than the original machine ever could. The infrastructure has become more than the hardware that originally carried it.
This is the difference between possessing infrastructure and possessing the capacity to reproduce it. A particular machine can be taken away, but the ability to build another machine can move between people. A website can disappear, but the knowledge of how to publish another one can survive. An administrator can leave, but the knowledge they carried does not have to leave with them if they have spent the time teaching someone else.
That is why the goal is not simply to have a server. It is to develop the ability to make another one, and then to make sure that someone else can do the same without you.
Imagine one collective learning how to maintain its infrastructure and then making a deliberate effort to teach three more people. Those people take what they learned into other projects. Some begin maintaining infrastructure for other collectives. They document what they know, someone else adapts that documentation, and eventually a person who once depended entirely on someone else for technical knowledge becomes the person teaching the next beginner.
The growth does not need to be spectacular. It can be slow, uneven, messy, and full of mistakes. That is still a form of resilience because the capacity is moving outward rather than accumulating in fewer and fewer hands.
Eventually, the network of people becomes more important than any individual node. A server can disappear without taking the knowledge of how to rebuild it with it. A person can leave without taking an entire technical capacity out of the movement. A collective can lose one piece of infrastructure and still have relationships with people who know how to reconstruct what was lost.
This does not mean that nothing can be taken from us. Servers can be shut down, websites can be taken offline, machines can be seized, domains can be lost, and infrastructure can still be disrupted. The point is that disruption does not have to become disappearance. What becomes harder to destroy is the capacity to rebuild when that knowledge no longer lives in one place or belongs to one person.
That is the wager behind autonomous movement infrastructure: not that nothing can be taken from us, but that what is taken does not take everything with it. If we teach what we learn, document what we build, and make technical knowledge something that moves through our movements rather than something that accumulates around a few people, then every new node becomes more than another machine. It becomes another place where the capacity to rebuild can live.
Each one, teach one. Become the thousand servers.
Supplemental recovery paths
These are focused recovery guides for specific situations. They are not the main course and do not replace G01–G13 or Lessons 1–12.
I have a NoBlogs / WordPress XML export and need to rebuild my site
Recover your blog, keep an independent backup, and leave enough information for someone else to move it again. Start with your XML file; no infrastructure knowledge is assumed. Plan several sessions: roughly 4–8 hours for a small hosted recovery, longer for large archives or missing media; self-hosting also includes the linked infrastructure lessons. You can stop when your site is back.
Path version 1. Practical and beginner usability tests are still pending; check each real result. Keep your XML and credentials on your own device.
Your export is a package of information taken out of your old publishing system. XML means Extensible Markup Language: text with labels that tell software what each piece means. It is data, not a running website. WordPress is software for publishing websites; NoBlogs used WordPress. A CMS, or content management system, is software like WordPress that lets you edit pages without writing a whole website yourself.
WordPress calls its XML export WXR (WordPress eXtended RSS). It may hold posts, pages, dates, authors, categories, tags, comments, extra descriptive data called metadata, and attachment records. An attachment record describes an image or file and may give its old address. It is not the actual image or file bytes. A list saying “photo.jpg lives here” is not a copy of photo.jpg.
Expect to rebuild the surrounding environment: the WordPress installation, passwords, some settings, widgets and server configuration. A theme controls appearance; a plugin adds functions. Their installed files are generally not in WXR. Actual media files may still need rescuing from old URLs (web addresses). Do not assume that seeing a picture address means the picture survived.
1. In your computer’s file manager, create a recovery folder. Copy the XML into an ORIGINAL subfolder. Make two additional untouched copies, with at least one on another drive/device you control. Make a separate WORKING copy for inspection/import. Do not edit the original or either safety copy. On a phone, use Files/My Files and copy to another device or drive before continuing. A second folder on the same phone cannot survive losing that phone.
2. Record filename, file size (Properties/Get Info), export date if known, former homepage URL, earliest/latest post dates you remember, approximate post count, author names, important pages and whether you have a separate media folder. Keep this recovery notebook beside your backup, not on the old host alone. No secrets belong in course notes.
3. Open only WORKING using Open with → a plain-text editor: Notepad on Windows; on Mac use TextEdit without converting or saving it as rich text. Use Find for wxr_version, wordpress.org/export, channel and a remembered post title. WXR commonly includes wp:wxr_version and a wordpress.org/export namespace. You do not have to understand the punctuation. A .xml filename alone proves nothing. Do not paste the export into a public validator: drafts, emails or comments may be inside.
4. Look at the beginning for the site title/link and at the end for closing channel/rss labels. Look for a known early post, late post and important page. These are clues, not proof of a complete export. An export filtered to one author/date/type can be valid but incomplete. If the editor cannot open a large file, keep it intact and use a host-assisted test import; do not truncate it.
5. Decide: appears to be WXR and contains expected material → proceed on the working copy. Wrong format, empty file, cut-off ending or missing expected years → preserve everything and request another export if possible. You can still recover a partial export, but record its gaps and never describe it as complete. If no usable WXR survives, choose the alternative handoff step.
A server is a computer answering requests. A host is the person or organization keeping that computer and your website available. You can rent that work or operate it yourself. Both can be deliberate choices. The goal is a recoverable blog, not proving that you can do every job alone.
A. Someone else hosts it for me. Shared hosting puts several customers on one server. Managed WordPress hosting includes some maintenance, but “managed” is not a fixed promise. Before paying, confirm: a WordPress installation; administrator access; WXR import through their supported tool; your XML file size; ability to fetch old attachments; enough media storage; HTTPS; custom-domain support if needed; downloadable content AND media backups; how restore works; updates/support responsibilities; recurring price and cancellation/export terms. HTTPS is an encrypted browser connection, with a certificate showing it belongs to the address you opened.
Hosting provider comparison3 = strong · 2 = workable with meaningful trade-offs · 1 = limited for this use · ? = not sufficiently verified
Prices are shown in U.S. dollars. FlokiNET and Koumbit amounts are approximate USD conversions checked 2026-09-25; verify the provider’s current billed amount before paying. Scores are not totals and should not be added into a winner. Different projects need different trade-offs.
What the scores mean
Control asks whether you can administer the system, run your own software, export it, move it, and avoid being trapped in a proprietary setup.
Privacy & data minimization asks what the provider collects or retains, how transparent it is about logging, and whether privacy-preserving account/payment options exist.
Resilience & recovery looks at backups, restore capability, DDoS handling, failure domains, and whether losing the provider would still leave you with a workable recovery path.
Movement accountability asks who the provider is accountable to: customers, members, a nonprofit collective, a cooperative, or simply company ownership. This is not the same thing as technical security.
NoBlogs / WordPress fit asks the narrow practical question relevant to this recovery path: can a former NoBlogs user actually get a WordPress/WXR archive online without discovering after paying that the host cannot do what they need?
Provider notes
1984 Hosting: Its current VPS line includes full root access, NVMe storage and DDoS protection, from $9.66/month; it accepts Monero. Its unmanaged VPS is the customer’s responsibility, so independent backups belong in your plan rather than being assumed from the host.
FlokiNET: Its public material describes full root access and included DDoS filtering; the Iceland VPS II is about $23/month for 2 cores, 2 GB RAM and 50 GB storage. Sabot’s direct 2026 correspondence additionally established the 30-day nightly VPS backup policy, minimal routine traffic accounting, and the shared-VPS DDoS freeze behavior.
May First Movement Technology: Shared hosting is substantially more capable than ordinary bargain hosting: WordPress auto-installation, SSH/SFTP, systemd services, MySQL/Postgres and multiple sites are included. Its model is membership-based rather than simply renting anonymous compute; VPS resources cost considerably more than its shared hosting.
Koumbit: Koumbit owns its servers in Montréal and describes itself as ethical, human-sized infrastructure participating in social movements. Its solidarity program provides free Plan A shared hosting to approved social-justice projects, while VPSs provide root access and configurable resources. VPS backups are an optional about $7/month per 50 GB, with five daily copies plus weekly copies for six months at a second datacenter.
La Contre-Voie: Their post-A/I offer is unusually specific: former NoBlogs users can request free 5 GB WordPress hosting through the end of 2026, evaluated individually, with hosting continuing without a required paid membership while capacity permits. Their normal web logging policy includes IP address, user agent and referrer for no more than 14 days.
This comparison is a starting point, not an endorsement. Political alignment alone does not establish WordPress compatibility. Verify the exact plan you intend to use against the provider’s current documentation and ask only for unanswered fields. Record provider, exact plan, price, support URL and confirmed import/backup limits below. Do not infer a VPS offer includes managed WordPress. If a host cannot explain how you will export files and recover elsewhere, choose another plan/provider.
B. I want to self-host it. A VPS (virtual private server) is a rented slice of a computer where you administer the operating system. You take on updates, security, backups and outages. Follow the linked infrastructure lessons and the specific WordPress practical before importing. Budget for ongoing maintenance, not just the first install.
C. Another destination. Another WordPress service may use a different import screen. Another CMS or static site may need a converter. Static means saved pages served without WordPress building each page from a database. Preservation can prioritize readable historic content over comments or editing. Choose the alternative handoff for an honest boundary on what this path currently supports.
Use the destination buttons above to select your trail. Changing your choice keeps your earlier activity history. Hosted recovery does not require Linux or SSH. SSH is an encrypted way to use a remote computer’s command line; you may leave that for later.
Choosing publishing software is a separate decision from choosing a host. A host keeps a site reachable; a CMS or publishing system determines how you write, organize, import, export and maintain the publication. Compare both before paying for anything. A friendly host with the wrong software is still the wrong destination.
Software options worth comparing
A host and a publishing system are separate choices. The software price below is not the whole operating cost: domains, hosting, storage, email, premium add-ons, and administrator labor can still cost money. Compare what you can actually import, operate, back up, restore and move, not by the length of its feature list.
Free software. Browser/PWA, desktop, and self-hosted editions cost $0 for the software; a shared public server still has whatever infrastructure costs you choose. Pricing/source
Publishing software shaped around independent publications, editorial collectives, archives and related media work. Its browser/PWA edition is local-first, so you can begin without first setting up a domain or server.
Migration reality: For a NoBlogs/WXR archive, this course has not yet verified a direct WXR import path. Treat migration as something to test before choosing it as the destination.
A deliberately small, writing-first publishing platform with ActivityPub support. It fits a simple blog or federated writing site better than a large general-purpose CMS.
Migration reality: The current main documentation does not advertise a direct WordPress/WXR importer. If WXR is all you have, assume conversion or manual migration is required until you verify a current tool.
Free to self-host. WordPress.com has a free hosted tier; paid hosting starts at $4/month billed annually, or $2.75/month on a three-year term. Pricing/source
The direct destination for a NoBlogs WXR export because NoBlogs used WordPress and this recovery pathway is built around WordPress’s own export/import model.
Migration reality: The official importer accepts WXR, maps authors and can fetch referenced attachments when the old files remain reachable. Hosting limits and missing source media can still interrupt an otherwise valid import.
Publishing software centered on publications, newsletters and memberships. It is useful when those editorial and subscription workflows matter more than WordPress compatibility.
Migration reality: Ghost provides import and platform-migration tooling, including WordPress migration guidance. Verify that the route matches the archive and media you actually possess before committing.
Free to self-host. Grav has no required hosted plan; you supply hosting, and the project notes it can run on a roughly $5 VPS. Optional premium plugins or themes may cost extra. Pricing/source
A flat-file CMS: core content lives in files rather than a SQL database. It can be attractive when you want a comparatively lightweight conventional site with portable content files.
Migration reality: Grav documents a WordPress migration path, but its current workflow assumes access to a working WordPress installation, WP-CLI and the uploads directory. A WXR-only NoBlogs archive may therefore need a different conversion path.
Colophon Free, self-hostable publishing software; browser/PWA mode is local-first.
WriteFreely Lightweight publishing platform with ActivityPub support.
WordPress General-purpose publishing CMS and the direct WXR destination covered by this recovery pathway.
Ghost Publishing platform centered on publications, newsletters and memberships.
Grav Flat-file CMS; verify migration support and required features before committing.
Build your replacement blog
Supporting practical · G04 · version 1
Hosted route: open your chosen provider’s official site and sign up for the verified WordPress plan. Save account recovery information in a password manager. The hosting account manages payment/services; the WordPress administrator account edits your blog. They may be connected by a host login button but are not necessarily the same account.
In the host dashboard, find Websites, Sites, Applications or WordPress. Use its documented Create/Install WordPress workflow on an empty project and temporary address. Do not select an existing website or overwrite its database. If WordPress is already installed, use its WordPress admin link. If the advertised plan has no installation/import route, send support your plan name, XML size and this request: “I need a new empty WordPress site with administrator access, WXR import, attachment retrieval and a downloadable database plus media backup. Where is the supported setup workflow for this plan?” Confirm this before proceeding or choose another provider. A missing button is a provider-specific difference, not your failure.
Create the WordPress administrator when prompted, or locate Users → Add New from the administrator supplied by the host. Use your own strong password and recovery address; store them securely. Your public author display name can differ from your login and legal name. Do not reuse old NoBlogs passwords. Self-hosters: you already created the installation/account; begin the settings checks below.
A database is the application’s organized store of posts, settings and other records. On hosted WordPress it is usually created for you. Import tools write the records; you normally do not touch database tables yourself. Know how to download a backup, not how to hand-edit every record.
In WordPress Settings → General set site title, tagline if wanted, site language and timezone, then save. A named nearby city handles seasonal clock changes better than a fixed offset. Do not casually change the WordPress Address/Site Address fields: that can lock you out. In Settings → Permalinks choose the old pattern if you know it (look at an old post URL); otherwise choose a maintainable pattern and record that old links may need redirects. A permalink is the lasting address of an individual post.
Write down the destination HTTPS URL and admin login URL. Open the site in a private browser window, where you are not logged in. Verify it loads without certificate warnings. Create a temporary test post, open its individual link and then remove that test post. A working homepage with broken post links is not ready. Ask host support to check permalink routing if needed. Keep the recovery site inaccessible to ordinary visitors while inspecting imported drafts/private details, using the host’s staging/access protection when available. WordPress’s “discourage search engines” setting is only a request, not access control.
General settings Technical reference rechecked 2026-09-17; practical lab testing still required.
Before import, record the destination’s WordPress version (Dashboard → Updates or Tools → Site Health → Info) and importer version (Plugins, where available), host/plan and browser. Save a backup/snapshot of this empty destination so a failed import can be retried cleanly. Never import into your only existing live site.
Open Tools → Import → WordPress in the WordPress dashboard. Install/run the official WordPress Importer if offered. Some managed services provide their own import interface instead; follow their documented WXR route. If installation is restricted, ask support to enable/run the supported importer. Upload WORKING, not a modified original. Do not choose an RSS importer just because WXR’s name includes RSS.
At author assignment, map each old author deliberately to a suitable destination author, or create one where supported. Record the mapping and public display names. Do not give every author administrator powers or publish private identifying details. Imported authors do not recover old passwords.
“Download and import file attachments” asks the new server to fetch referenced files from their old addresses. Choose it if you want those copies and the old source is reachable. It cannot reconstruct missing bytes. Start once, leave the tab open, and record every message. The official importer’s URL rewriting has changed across versions; never assume every old link has been replaced.
Classify the result using Posts, Pages and Media plus actual public pages: succeeded means expected items arrived and checks below pass; partly succeeded means content arrived but some items/media failed; failed means no usable import or a fatal error. A final completion message is a starting point for inspection, not proof that everything survived.
Upload too large means the host rejected the file size. Timeout means the operation ran longer than allowed. Out of memory means its working space ran out; a blank screen may have the same cause. Save the exact error, XML size, versions and what already arrived. On shared hosting ask support for a one-time assisted import or suitable limits. On your own machine review PHP/web-server limits using official documentation; do not set everything to unlimited.
Before retrying, inspect counts and sample posts. Do not repeatedly click Import: duplicate detection is not a full rollback and can vary. If you have done no new work since the empty snapshot, restore that empty destination or create a second empty test installation and retry once after fixing the cause. Otherwise back up current work and arrange a targeted retry with the host. For a large file ask for a WXR-aware split or command-line import that preserves dependencies; do not cut XML by arbitrary lines or use an unknown upload service. Record which part ran and whether attachments were fetched to avoid repeated requests.
Make a media inventory in your recovery notebook: old URL, post/page using it, type, new file URL, checked result, and any known loss. Check images, audio, PDFs and other downloads, featured images, inline media and old attachment-page links. Featured images are the main pictures a theme displays beside posts; they may be stored separately from the pictures inside post text.
A picture visible in a post may still be loading from NoBlogs. In WordPress Media → Library, open an item and inspect its File URL; also open the image/file from the actual post (right-click/open image in new tab, or long-press on a phone). Compare the hostname with the new host’s address. A provider may serve uploads from a separate media hostname: confirm who controls it and whether its files are in your export. An old remote URL still working is not an independent copy.
Download a sample PDF, play audio beyond its opening seconds and open full-size images. Check both an early and a recent post, pages, featured images and a few items from every file type. If the archive is small, check every item; if large, record your sampling and keep a remaining-work list. Count and locate important media explicitly rather than assuming sampling proves completeness.
If a file remains reachable, save that individual file to your recovery media folder, then upload it through Media → Add New on the replacement. In the affected post/page, replace the old image/link with the new Media Library item; set the featured image again where needed. Save and test the public page. Keep the old-to-new URL mapping for future redirects. For many files arrange a paced transfer with the operator/host. Work sequentially, stop on errors or throttling, and do not run parallel crawlers or repeated full imports against a struggling source. No scraping is required by this course.
If the old file is unreachable, check your own devices, earlier backups and copies held by the original publisher. A cached thumbnail may not be the original quality. Mark truly unavailable items clearly and remove misleading broken download promises; never invent replacement documentary media. “Verified as far as possible” means readers can use the recovered site and you have a precise loss list, not that every file was magically restored.
Content recovery gets the writing and records back. Site reconstruction makes those records usable as a website again. WXR may carry menu data, but it does not guarantee the old layout or every configuration will reappear. Start with a maintained theme you can understand; do not hunt down abandoned plugins just to recreate a historical appearance.
Check Appearance → Editor/Navigation for a block theme, or Appearance → Menus for a classic theme. Add links to important pages, the blog and categories, then open every menu link as a visitor. Menu controls vary by theme. In Settings → Reading choose recent posts or a static front page (one fixed page), and select the correct home/posts pages. A blank homepage can simply be the wrong page choice.
Compare old and new: About/contact pages, site title/tagline, category and tag archives, chronological ordering, author bylines/display names, comment visibility/moderation and dates. Inspect imported drafts/private/password-protected posts before removing staging protection. Recovering something does not mean making it public. A restored contact form may need new configuration; do not assume its email delivery works.
Rebuild widgets or equivalent blocks (sidebar/footer elements), choose a readable mobile layout and test on a narrow screen. Use only maintained plugins needed for actual features. In posts/pages inspect internal links and old attachment links. Where an old path changed, record old → new and configure a permanent redirect using the host’s redirect tool or a maintained supported solution. A redirect tells visitors to use a different URL. Test that it goes to the intended page, not a loop. You can redirect only on a hostname you or a cooperating operator control.
Open several oldest/newest posts, a page, each author/category archive and a comment thread while logged out. Check non-English characters and formatting. If an archive is too big to exhaustively review now, prioritize important content, record remaining gaps and publish a clear recovery note.
Permalinks Technical reference rechecked 2026-09-17; practical lab testing still required.
Before changing the old domain, read the linked backup lesson in the context of this blog. A backup is a separate recoverable copy; a restore is actually rebuilding from that copy. A host snapshot helps undo a mistake while the host exists. An application backup may contain WordPress files/database but still live only on that host. An independent copy is stored somewhere you control outside that provider. The course recovery card backs up COURSE PROGRESS, not your blog or XML.
Create a dated folder outside the hosting account. Keep the untouched original XML, a fresh WordPress Tools → Export → All content export, actual media files, and a database/application backup as the destination permits. A database dump commonly ends in .sql: it contains database records, not upload files. Get both. Use the host’s Backup/Export download workflow and File Manager to download wp-content (including uploads, themes and plugins), plus configuration such as wp-config.php where permitted. If a managed service hides the database, get its documented portable export with media and a tested fresh-site import route. If it supplies neither, that destination does not meet this pathway’s independent recovery requirement.
On the self-hosted layout above, pause editing/uploads while taking a matching database/files copy. Treat the database dump and filesystem archive as one backup set created at roughly the same point in time. In SSH run sudo mariadb-dump --single-transaction --result-file=/root/blog.sql blog, then sudo chmod 600 /root/blog.sql, then sudo tar -czf /root/blog-files.tar.gz -C /var/www blog -C /etc/apache2 sites-available. For the normal InnoDB tables used by WordPress, --single-transaction produces a consistent database snapshot without locking tables for the duration of the dump; pausing site writes still helps keep the database and uploaded files aligned as one recovery set and avoids relying on that guarantee for any non-transactional tables. Check the command exit status and confirm the dump is non-empty. For the normal InnoDB tables used by WordPress, --single-transaction produces a consistent database snapshot without locking tables for the duration of the dump; pausing site writes still helps keep the database and uploaded files aligned as one recovery set and avoids relying on that guarantee for any non-transactional tables. Check the command exit status and confirm the dump is non-empty. These copies are still on the server until downloaded. To download without exposing these files, first run whoami in SSH and note that username. In the commands below replace LOGIN with it. Run sudo install -o LOGIN -m 600 /root/blog.sql /home/LOGIN/blog.sql and sudo install -o LOGIN -m 600 /root/blog-files.tar.gz /home/LOGIN/blog-files.tar.gz. If your home is not /home/LOGIN, use the location shown by pwd immediately after a new SSH login. On YOUR COMPUTER, open Terminal (Mac/Linux) or PowerShell (Windows), change into your backup folder using cd, and run scp LOGIN@SERVER_IP:blog.sql . and scp LOGIN@SERVER_IP:blog-files.tar.gz ., replacing SERVER_IP with this server’s address. The final dot means the current local folder. This uses the same SSH key/login as Lesson 3. Open the downloaded archive with your file manager and check uploads and configuration exist. Never publish it. Do not place backups under the public web folder. Check command errors and file sizes; a failed dump is not a backup. After the downloaded copies have been verified and at least one independent copy is safely stored, remove the temporary database/archive copies from the server’s root and login home directories so credential-bearing backup files are not left there indefinitely. After the downloaded copies have been verified and at least one independent copy is safely stored, remove the temporary database/archive copies from the server’s root and login home directories so credential-bearing backup files are not left there indefinitely.
Add a recovery README: provider/plan, site URL, domain/registrar, DNS record copy, WordPress/PHP/database versions, theme/plugins, media losses, export date, backup filenames, restore steps, update responsibilities and where credentials are held securely. Configuration and database files can contain passwords/personal details: keep these backups private, preferably encrypted, with the key separately accessible to the agreed successor.
Use a second empty protected test site to restore from the downloaded copy, not from a host-only snapshot. For a portable WXR/media route, repeat this path’s installation/import/media steps using your local files and verify important pages. For hosted database/files backups use that host’s documented restore tool on the second site; verify the tool accepts the DOWNLOADED files. For the self-hosted layout, create another empty machine using the setup steps above and a different test hostname. From your computer upload the local copies using scp blog.sql blog-files.tar.gz LOGIN@NEW_SERVER_IP:./. In SSH on that NEW test machine run mkdir restore-check and tar -xzf blog-files.tar.gz -C restore-check. Inspect restore-check/blog/wp-content, then copy it over the NEW disposable installation with sudo cp -a restore-check/blog/wp-content/. /var/www/blog/wp-content/ and sudo chown -R www-data:www-data /var/www/blog/wp-content. Keep the NEW wp-config.php/database credentials and Apache hostname; do not copy old secrets/config blindly. Only on this empty test destination, and only after confirming it contains no data you need to preserve, run sudo mariadb blog < blog.sql to load the backup records. A restore command is destructive to whatever schema/data already occupies the target database; the empty disposable destination is the safety boundary. In sudo nano /var/www/blog/wp-config.php add define('WP_HOME', 'https://YOUR_TEST_HOSTNAME'); and define('WP_SITEURL', 'https://YOUR_TEST_HOSTNAME'); above the stop-editing comment, replacing the hostname. These temporarily override the old saved addresses so you can inspect the restore. Imported media links can still point at the old destination: compare file URLs, open downloaded uploads directly at the test hostname, and follow the official migration reference before a permanent move. Log in using the backed-up WordPress administrator account and verify content plus locally restored media. Keep this duplicate protected or remove it after the test; never test contact forms/notifications against real recipients. Record exactly how the backup was restored, what failed and what another person would need. Do not overwrite the working replacement to prove a point. Only confirm this checkpoint after the independent copy and a successful test restore exist. Keep at least two copies and set a repeating reminder in your own calendar to update them.
First use the dependency-map lesson to identify who controls the domain, DNS, hosting and backup. Then use the linked DNS and migration lessons for this specific job: make your old domain reach the verified replacement. Hosted learners need their DNS/migration concepts and web-record checks; the Linux/server exercises inside those lessons can wait.
If the old address is a subdomain under noblogs.org, you usually cannot change its DNS yourself. Record that you do not control it, keep the new destination address, and request a redirect only if the old operator can offer one. Do not wait indefinitely for a domain you cannot control. A new working public address is a valid recovery. Tell readers through channels you control; this course sends no announcements.
If you control the domain, sign into your DNS provider and download/export the current record set or save complete screenshots and values before editing. Include mail records. Add the domain in the replacement host’s dashboard first; follow its exact web-record instructions and certificate setup. Confirm how its WordPress address change is handled and how to reverse it. A domain registration transfer is not necessary just to change hosting.
Plan a quiet cutover and temporarily pause posting/comments so changes are not split between sites. Preserve MX records (mail routing) and TXT records used for mail authentication (SPF/DKIM/DMARC). Keep mail-related hostnames and unrelated services. Change only the instructed web A/AAAA/CNAME records; those map names to addresses or other names. A stale AAAA (IPv6 address) can send some visitors to the wrong machine. Do not replace nameservers or use “reset DNS” as a shortcut: that can remove working email configuration. TTL is the time an answer may remain cached. If you lower it for a migration, do so far enough in advance that caches holding the previous, longer TTL have time to expire; changing the authoritative TTL does not retroactively shorten an answer already cached elsewhere.
Use Lesson 8’s verification/rollback process. After changing DNS, query an authoritative nameserver directly and compare it with one or more recursive resolvers; then check the new domain over HTTPS, individual post URLs and media from another device/network. On self-hosted WordPress add the final hostname to Apache and obtain its certificate before changing the WordPress addresses; use the official migration guidance for URL changes in stored content, not blind database text replacement. Recheck internal links and redirects after the address changes.
If checks fail, restore the saved web records and prior application address using the host’s documented rollback. Keep the old service temporarily where possible and reconcile any new posts/comments before retry. If the old site is gone, say rollback is unavailable; retain the independently verified replacement URL and backup. Verify mail still works through your normal mail client yourself. Do not change email service as part of this move.
DNS record types Technical reference rechecked 2026-09-17; practical lab testing still required.
Check the recovered site and leave a handoff
Supporting practical · G12 · version 1
Open the final public address while logged out. Remove staging access restrictions only after checking that drafts, private posts and personal details stay private. Verify important posts/pages, menu links, media/downloads, author credits and HTTPS again. Recheck the backup after any domain/address or reconstruction changes; keep a fresh independent copy that matches the final site and document the changes from your restore test.
Write a short handoff in your recovery folder: “The blog is at __. It runs on __. The domain is controlled through __ / not controlled by us. Backups are at __, dated __. To restore, follow __. Missing media/remaining repairs: __. The person responsible for updates is __. Access can be recovered through __.” Keep passwords out of the document; point to the agreed secure way to obtain them. Another authorized person should be able to follow the instructions without needing undocumented knowledge from the original administrator. Have that person locate the independent backup and talk through the first restore and account-recovery steps; every point where they need hidden context is a handoff defect to fix. Have that person locate the independent backup and talk through the first restore and account-recovery steps; every point where they need hidden context is a handoff defect to fix.
Use the checks below to record work actually performed. Reading this page does not restore anything. Once all checkpoints on your chosen WordPress trail are self-confirmed, the pathway will show its recovery-complete exit. With JavaScript disabled or in the offline edition, review each checklist manually; if every applicable item has been done, the same exit applies.
You do not need to complete the other twelve lessons to finish hosted blog recovery. You can come back later to learn more, with your recovery work and older activity attempts still saved.
Follow these existing lessons in the order linked below: dependency map; DNS; disposable Linux/SSH; first disposable page; exposure. DNS is the system that tells browsers where a name leads. A domain is a name you can register, such as example.org. A registrar is the organization through which you register it. Nameservers are the computers publishing its DNS answers. You are learning these now because your replacement blog needs a reachable, controlled address.
Do the exercises on disposable infrastructure first. Then create a separate empty Ubuntu 24.04 LTS VPS for this practical; LTS identifies an Ubuntu release maintained for longer. Do not run this installation on Sabot, an existing blog, or the same machine still serving the Caddy/nginx exercise. Two web servers can fight over the same ports. A port is a numbered entry point to a service.
Use Lesson 2 to point an unused test hostname you control (for example recovery.your-domain.org) to the new machine. Keep existing website and email records unchanged. You need working SSH with sudo permission (permission to administer the machine), a provider console for recovery, and ports 80/443 reachable for the website. Use Lesson 5 to allow SSH before enabling a firewall; never expose the database port 3306 publicly. Check both the provider firewall and the server firewall. Record the actual Ubuntu version with cat /etc/os-release. Ubuntu Server enables unattended security updates by default on standard installations, but you still need to verify the update policy, third-party repositories, reboot requirements and service restarts for the machine you actually received.
The following practical is specifically for this fresh Ubuntu/Apache environment. If you chose a different operating system or web server, use its current official installation guide and record the adaptation for review, or use hosted recovery. Do not paste commands intended for another system and hope.
This practical adds the application the generic web-page lesson does not provide. Apache serves requests, PHP runs WordPress, and MariaDB stores organized records in a database. The database account below is for WordPress to use; it is different from your later browser administrator account. Run commands in the SSH terminal on the new machine only. Stop at any error and save the message without passwords. This procedure needs practical verification in the stated environment; it is not marked tested.
1. Install the packages, one command at a time: sudo apt update sudo apt upgrade If the upgrade reports that a reboot is required, reboot the disposable server and reconnect before continuing. Do not begin an application install while the machine is half-updated.
sudo apt install apache2 mariadb-server libapache2-mod-php php-mysql php-xml php-curl php-gd php-mbstring php-zip php-intl curl unzip Check versions with php -v, mariadb --version and apache2 -v. As of the 2026-09-17 technical review, WordPress recommends PHP 8.3 or newer, MariaDB 10.11 or newer OR MySQL 8.0 or newer, plus HTTPS. Compare your actual versions with the current WordPress requirements linked below because these recommendations change. If the distribution’s supported packages no longer meet the current baseline, stop and update the practical rather than adding an unknown package repository.
2. Create the application database. Generate a long unique password in a password manager; use letters/numbers here so quotation marks cannot break the example. Run sudo env MYSQL_HISTFILE=/dev/null mariadb to open the database prompt without writing this session to a SQL history file. If that does not open the MariaDB administrative prompt on the image you actually received, stop and use that image/provider’s documented local database-administration method rather than changing database authentication at random. At the prompt enter the following statements one at a time, replacing REPLACE_WITH_UNIQUE_PASSWORD before entering it: CREATE DATABASE blog CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'blog'@'localhost' IDENTIFIED BY 'REPLACE_WITH_UNIQUE_PASSWORD'; GRANT ALL PRIVILEGES ON blog.* TO 'blog'@'localhost'; EXIT; Keep database name blog, user blog, host localhost and its password in your password manager. Do not put the password in course notes. You created an empty container for records; you need not edit individual tables.
3. Download the application in your SSH home directory: curl --fail --location https://wordpress.org/latest.tar.gz --output wordpress.tar.gz tar -xzf wordpress.tar.gz sudo mkdir /var/www/blog sudo cp -a wordpress/. /var/www/blog/ sudo chown -R www-data:www-data /var/www/blog If /var/www/blog already exists, stop and inspect it; never overwrite an existing site. Here www-data is Apache’s service account. Giving the web-service account ownership of the whole tree is a simplified choice for this single-site disposable training environment. WordPress and Ubuntu guidance recommend stronger per-site/user separation for shared or multi-site hosting so one PHP application cannot freely alter another. Do not copy this ownership model into a shared production server without designing permissions deliberately. Install only maintained plugins you need, keep updates/backups working, and never solve permissions with “777.”
4. Run sudo nano /etc/apache2/sites-available/blog.conf. Nano is a terminal text editor: paste the following, replace recovery.your-domain.org with your real test hostname, then Ctrl+O, Enter to save and Ctrl+X to exit: <VirtualHost *:80> ServerName recovery.your-domain.org DocumentRoot /var/www/blog <Directory /var/www/blog> Options -Indexes AllowOverride All Require all granted </Directory> </VirtualHost> Run sudo a2enmod rewrite, then sudo a2ensite blog. If the stock 000-default site is still enabled and you do not need it for anything else on this disposable machine, disable it with sudo a2dissite 000-default so unmatched requests do not fall into a second default site. Then run sudo apache2ctl configtest. Only if the result says Syntax OK run sudo systemctl reload apache2. If Apache will not start, use sudo systemctl status apache2; check for another web service on ports 80/443 rather than disabling random services.
5. Before submitting any password in a browser, enable HTTPS. Install Certbot using its current official Apache-on-Linux instructions rather than mixing an old distribution package, pip install and snap install on the same machine. Current Certbot instructions recommend the snap for most Linux users. Make sure snapd is available; if an OS-package Certbot is already installed, follow Certbot’s current instructions to remove that package before using the snap so two installations do not compete. Install with sudo snap install --classic certbot. If the certbot command is not already available, the current instructions use sudo ln -s /snap/bin/certbot /usr/local/bin/certbot. Once Certbot is installed, run sudo certbot --apache -d recovery.your-domain.org with your actual hostname. DNS must already resolve to this machine and the HTTP-01 validation path must be reachable on port 80; a stale or incorrect AAAA record can send validation to the wrong IPv6 host. Follow the prompts, enable HTTP-to-HTTPS redirection when appropriate, and do not bypass browser certificate warnings. Run sudo certbot renew --dry-run to test the installed renewal timer/job, then confirm HTTPS opens without warnings. If Certbot changes its supported installation method, follow its current official instructions instead of preserving these commands by habit.
6. Open the HTTPS test address. In the WordPress setup screen enter database blog, user blog, the saved database password and localhost. Keep the default table prefix on this new empty database. Run installation and create your browser administrator account with a different unique password and a working recovery email you control. If “Error establishing a database connection” appears, compare the four database fields and sudo systemctl status mariadb; do not expose the database to the internet. If you see PHP source downloaded/displayed instead of a setup screen, stop Apache with sudo systemctl stop apache2 and fix PHP integration before continuing. Finish the common blog-settings step next.
This is a planning handoff, not a claim that your blog is restored. There is no universal “import XML” button. Confirm the target’s documented WXR importer/converter, supported versions, content types and how you will publish new posts afterward. If no supported conversion exists, rebuilding pages from recovered text is real work and must be planned as such.
Create a handoff folder with the untouched export copies, media copies you possess, a list of old URLs, expected post/page counts and dates, author attribution, and a written list of missing material. Keep drafts and personal comment details private. Ask whoever will help to work from another copy and return the converted files, conversion instructions and a list of losses. Keep control of your originals.
Test one representative post, page, category, multiple-author example and media link at the proposed destination before committing to it. Check dates, links, Unicode text and whether comments become public text, disappear, or remain moderated. Static archives usually do not provide live commenting; another CMS may discard WordPress-specific formatting. Choose these tradeoffs deliberately.
You can stop here with a preservation/handoff plan, or switch to hosted/self-hosted WordPress above to follow the complete recovery workflow. This handoff does not trigger “Your site is back.”