The manual lists five directories that make up the node’s recoverable state: configuration, internal state, logs, spool and crash dumps. The paths are given as defaults and may differ on a particular installation.
Restoring is simple and crude: stop the engine, put the directories back, start it. The manual offers no way to restore on the fly.
What stands behind each directory. The configuration is settings and secrets; losing it is reversible if the file is assembled again. The spool is messages not yet sent: losing it means losing messages. Internal state is what the engine remembers between starts. Logs and dumps are needed for investigation, not for operation.
The order of directories in the list is not the order of importance. The configuration can be assembled again, the spool cannot.
What exists: the Hub assembles the configuration itself, keeps its versions and can roll back to the previous one. That is, the configuration is recoverable — from the Hub, not from a node copy.
But the spool cannot be recovered by anything. Messages queued on a node are lost together with the machine: the Hub does not have them; it only knows they were handed to the node.
Until the module appears, this means a simple rule: no destructive actions on a production node without testing on a staging environment. There will be nowhere to restore from.
What is in which directory and what losing it means:
| Directory | What is inside | If lost |
|---|---|---|
| configuration | settings, passwords, signing keys | recoverable from the Hub; keys — if saved |
| internal state | what the engine remembers between starts | recoverable, but the node will “forget” what it accumulated |
| spool | messages not yet sent | messages lost irreversibly |
| logs | traces for investigation | investigating the past becomes impossible |
| crash dumps | material for the vendor | nothing needed for operation |
A copy from a running node can be taken only via a volume snapshot. Ordinary copying of the spool on the fly gives an unusable copy — the engine is writing to it at that very moment.
Signing keys are worth storing separately from the node. Losing them means changing the selector and the DNS record, not restoring; this is the most expensive part of the configuration.
# taking a copy: configuration and state can be copied on the fly tar czf /backup/pmta-etc.tgz /etc/pmta/ tar czf /backup/pmta-state.tgz /var/lib/pmta/ # the spool — only from a volume snapshot or a stopped node# tar czf /backup/pmta-spool.tgz /var/spool/pmta
what people get wrong and how it ends3 mistakes▶
§ 1.8
§ 1.8
§ 1.8
3 relations
Running without root privilegesA related procedure: they share some of the steps. § 1.8Removing the engineA related procedure: they share some of the steps. § 1.8spool-delete-corruptedGlobalA corrupted file is what restoring from a backup will not save: the message in it can no longer be read. inferencelog-fileGlobalThe log is usually not included in a backup: it recovers by itself and takes up a lot of space. § 1.8deliver-only<spool>The standard way to bring up a failed node’s queue: attach its spool and drain it. § 3.3.2.2Switching over to a standby nodeA related procedure: they share some of the steps. inference
pmta test config pmta show status
3 articles
◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.