Understanding a server you inherited: read before you change

A Proxmox you did not build has landed in your lap. The person who built it is gone, there is no documentation, and you are responsible for it now. The first instinct in this situation is to poke something and see what happens. That is exactly the thing not to do first, because you do not yet know what is attached to what.

The first week is a reading week. Every question below can be answered without changing anything.

First question: what runs here

Not how many machines there are, but which of them actually do work. On inherited servers there are almost always machines sitting switched off that nobody dares delete. You are not going to delete them now, you are only going to list them.

Second question: where does each machine's disk physically live

This is the question list views answer worst, and it is the question that decides the most. Because the answer tells you this: does the death of one disk take out one machine, or eight.

Follow the chain to the end: machine, virtual disk, storage, pool, physical disk. Seeing that the virtual disks of eight machines come down to the same physical disk is the single most valuable thing you can learn about that server.

Third question: what is backed up, and how old is the newest one

Do not look at whether backup jobs exist, look at the age of the newest backup. Finding a backup job that stopped quietly is a common thing on inherited setups, and learning it in the first week is far cheaper than learning it in the sixth month.

Fourth question: who can get in here

Not how many users there are, but which of them is allowed what. On inherited systems there are accounts of people who left, forgotten automation keys, and permissions nobody remembers granting. Write these down too, for now.

Fifth question: how far behind is it

Look at the pending updates, and at whether there is a kernel installed but not rebooted into. The second one matters: the machine may look up to date while actually running on the old kernel.

The "it has run for two years, so it must be solid" trap

Uptime is not health, it is the absence of a reboot. A machine that has run for two years is a machine that has been untested for two years. Services started by hand and never added to startup, mounts never written into the configuration, all of it sits unexercised through those two years and comes out together at the first reboot.

That is why the first planned reboot on an inherited server should happen at a moment you choose, with a backup in hand. The moment you did not choose arrives sooner or later.

Write down what you find

The document you write in the first week is the document that saves you in the sixth month. It does not have to be long: which machine does what, where its disk sits, whether it is backed up, who can reach it. Even five lines is infinitely better than nothing.

Do not delete anything for a while

An unlabelled machine nobody can identify is a risk, but deleting it is a bigger risk. Turn it off and wait. If nobody screams for two weeks, then you decide. Learning after deleting cannot be undone; learning after switching off is one button.

What Atlas does

Atlas draws two chains, and on an inherited server those two chains are exactly what you need.

The resource map goes from the machine all the way down to the physical disk: the machine, its processor and memory share, the virtual disk, the storage, the pool, and at the bottom the real disk. So the question "where does this machine's disk actually sit" is answered by following the line rather than opening each machine's configuration one by one. Seeing that eight machines come down to the same disk happens on that same screen.

The network map draws the other chain: machine, bridge, physical port, outside world. Put together, you can read what a server you did not build looks like in a single afternoon.