Server maintenance: an operating plan for updates, backups and real recovery

Every task needs a responsible role

A server can be technically monitored yet remain down for hours if nobody responds to the alert. The operating plan therefore starts with applications, contacts and business hours. Record who handles an incident technically, who decides its priority and who gives business acceptance to the restored service. Deputies must be able to access the same necessary information.

One person may hold several roles. What matters is that no role remains unassigned. With a service provider, agree responsibilities and availability in writing. A promised response time initially means work begins; it does not automatically guarantee a fully restored application within that same period. Separate these targets in the service specification.

A maintenance rhythm with a justified purpose

The following plan is our starting template for a small environment. It is not a universal standard. Frequency and urgency depend on the business, the system's exposure, vendor notices and agreed recovery targets. Critical new information is handled outside routine windows when necessary.

For an application with a very tight recovery target, quarterly testing may be too infrequent. Conversely, not every small, unchanged supporting application needs a full monthly rebuild. Choose the scope according to risk and change it after failures, major updates or a backup change. A rigid calendar does not replace informed assessment.

Updates finish with a functional check

NIST describes patch management as identifying, prioritising, acquiring, installing and verifying updates. The guide classifies it as preventive maintenance. In practice, an update is complete only when the installation and the required service have been checked. NIST SP 800-40 Rev. 4: Patch Management Planning ↗

Before the window, clarify dependencies, vendor notices, available backups and the rollback route. For important applications, try the change first in a suitable test environment. The team defines how long to wait for a successful update and when to switch to the prepared rollback. A database schema may not be reversible simply by restoring a program file.

• Before: document affected services, approval, backup state and expected interruption.
• During: record changes and deviations without opening several unplanned lines of work at once.
• After: check sign-in, the core business function, background jobs, database connectivity and monitoring.
• Completion: record new versions, confirm required restarts and assign unresolved faults.

Plan backups from the recovery target backwards

RPO is the target for tolerated data loss, expressed as a time interval. RTO is the target recovery duration. If no more than 30 minutes of orders may be lost, a daily backup alone cannot meet that target. Whether more frequent backups, transaction-log backup or another method fits depends on the application and data storage.

In its backup-concept module, the BSI emphasises documented recovery, among other things. Missing instructions or unavailable information can delay or prevent recovery. Documentation must therefore remain accessible even if the affected server and its normal access routes fail. BSI: CON.3 Backup Concept, 2022 edition ↗

Check separate copies, suitable retention and separation of access from the production environment. For encrypted backups, the necessary keys and permissions belong in the recovery plan. They must remain securely available without being exposed in general documentation. A database backup should also provide a consistent state; arbitrarily copying currently open files is not a reliable assumption for this.

Example: why a two-hour restore target is missed

A hypothetical service must be usable again within two hours of an outage. The backup contains 200 GB in decimal units. For the test, we assume an effective transfer rate of 400 Mbit/s. Data transfer alone therefore needs 200 × 8,000 / 400 = 4,000 seconds, or around 67 minutes. All the following durations are our own model assumptions.

The result is approximately two hours and 37 minutes, missing the target. A faster connection alone will not necessarily solve every problem. Possible measures include a prepared target system, a more readily available backup, fewer manual dependencies or a technically different recovery method. Measure again afterwards. An optimistic spreadsheet value does not count as a met target.

Connect alerts with an action

A simple ping check reports that a computer responds. It does not show whether a customer can sign in or save an order. Combine technical signals with a low-impact check of the required function. An alert should identify the affected application, its urgency, who responds and where the appropriate instructions are.

Observe trends as well as errors: spare capacity, age of the last successful backup, rising response times and expiring certificates. For storage space, the change matters. Our calculation with 500 GB free and growth of 20 GB per day gives a theoretical 25 days until full; maintenance reserves and peaks shorten the usable period. This allows expansion to be planned before an application refuses writes.

Remove or change alerts that remain meaningless. An inbox full of identical messages makes real outages harder to recognise. Recurring errors need a root-cause action with a deadline. Muted alerts need an end date or a documented reason so they are not forgotten after maintenance.

Maintain support lifetimes and handover information too

Maintain a lifecycle calendar for the operating system, database, application and hardware. Support scope depends on the product, version and any purchased contract. Canonical, for example, distinguishes different maintenance and support coverage in Ubuntu's lifecycle. Check your installation's actual coverage rather than just the age of the version number. Canonical: Ubuntu release cycle and support coverage ↗

Start an upgrade early enough to test compatibility and rollback. Keep the inventory current too: which application needs which database, interface and responsible person? When handing over to a new service provider, information and necessary access must be transferable in an orderly way. Documentation is part of the operated system.

A monthly report that leads to decisions

A useful operations report does not need twenty charts. It names relevant interruptions, completed changes, the latest restore evidence and the next capacity or support limits. Open items have an owner and a date. Business owners can then see which limitation remains and which decision is needed.

Failed backups or a missed recovery target must be visible in this report. Only a corrected cause and a successful test close the item. Maintenance then changes from an elusive monthly charge into a verifiable service whose contribution to the company's ability to work remains understandable.