Self-Managed Database Problems: Patching, Backups and Upkeep

Self-managed database problems are the upkeep jobs your own team takes on once it runs the database itself. There are eight of them: patching and version support, backups and restore evidence, point-in-time recovery, high availability and failover, monitoring and night on-call, capacity and storage growth, hardening with access review and audit logs, and knowledge held by one person. With no provider in the picture, each of these jobs sits with the in-house team.

This article is for IT heads, infrastructure leads and CIOs in mid-size Indian and GCC firms. Their teams run their own databases. Some of those databases sit in the firm’s own data center. There, on premise database challenges include the servers as well as the software. Others run on raw cloud virtual machines, but the install and the patching still stay with your team. A managed database is one where a provider runs the engine, its patching, its backups and its failover. Move steps, scored checks and a side-by-side comparison of the two models sit outside this article.

Self-Managed Database Problems at a Glance: Eight Jobs Your Team Owns

Each of the eight jobs below lands on someone in your team every week. It lands there whether or not it appears on a project plan.

The database engine is the software that stores the data and answers queries, and your team runs it.

The work lands on salaried staff. It also shows up as new projects that slip while the upkeep gets done.

Self-Managed Database Problems Start With Patching and Version Support

The release schedule of the database engine sets the pace for patching. Your team’s calendar has to fit around it. Each release also adds a window to plan, a restart to run and a check to sign off afterward.

Minor Fixes Arrive Every Quarter Whether or Not a Window Is Open

Engine projects publish their own support policies, and PostgreSQL gives a clear example. As of November 2026, the PostgreSQL Versioning Policy states that each major version receives bug fixes, and security fixes where needed, in minor releases at least once every three months. The project recommends running the current minor release for your major version.

On a database you run yourself, each of those releases becomes planned work. First, someone reads the release notes and decides whether a fix matters for your set-up. Then they book a restart window with the application owner. They also apply the update to a test copy and check the live database after the restart. In Signisys’s working view, a minor update can slip when no window is agreed. A quarter later, the next release arrives on top of it.

Patching is where self-managed database problems start, in the gap between published releases and agreed windows. A database two or three minor releases behind carries known, published fixes that your team has not applied. For that reason, we recommend a standing window on a set rhythm. The business agrees it in advance, and a named owner confirms each update went in.

The database is also one system among many. The same discipline belongs in the patch and fix routine for every other system. The database window can sit inside that routine.

Major Version Upgrades Need Planned Work and a Rollback Route

Major versions follow a slower rhythm with larger work. The same policy says the project releases a new major version about once a year. It also supports each major version for five years after its first release. After that period, the version falls outside the project’s support.

A major upgrade changes how the engine stores data on disk. According to the policy, a major upgrade needs a dump and reload of the database or the project’s upgrade tool. In practice, that means planned work across several teams:

• a test copy of the database on the new version;
• application tests against that copy, including reports and batch jobs;
• checks that each extension the database uses has a release for the new version;
• a rollback route, with a backup taken before the switch and a timed run-through of the return path.

Each item also needs people from the database, application and infrastructure sides in the same week. When the work keeps moving to a later quarter, versions can drift apart across the estate. Some databases then sit two major versions behind others. The team then supports several versions at once, each with its own quirks and its own support period to track.

Operating systems and commercial database engines have their own support dates, and a separate article on our blog covers them.

Backups and the Evidence That Restores Work

A backup job that reports success shows only that the job finished. It says nothing about whether the copy restores or how long a restore takes. It also says nothing about whether the data inside is complete. Restore evidence fills that gap.

A Restore Routine With a Named Owner and Evidence

A restore routine answers three questions: who restores, at what interval, and what they keep as evidence. We recommend writing all of them down for each production database.

The owner is a named person, with a named second. The business owner agrees the interval for each database, based on how much the data matters. It sits in writing next to the database’s name. For example, a payments database may need a tighter interval than an internal wiki.

The evidence is what an auditor or a new IT head can read later:

• the date of the restore and the backup it came from;
• the time taken, from start to a database that accepts queries;
• row counts or checksums compared against the source;
• an application check, where a user confirms key screens load;
• a sign-off by the database owner.

Disaster recovery tests sit inside this routine as well. A full recovery exercise is a restore under harder conditions, on other hardware or at another site. NIST SP 800-34 Rev. 1 was written for federal information systems. It treats plan testing, training and exercises as one step of the process. For moderate-impact systems, its exercises include recovery of the system from backup media.

The risk here sits between backups that run and restores nobody has tried. Some backup copies look healthy and still fail; see copies that look fine until someone tries a restore.

Point-in-Time Recovery and the Logs It Relies On

Point-in-time recovery means restoring a database to a chosen moment, such as one minute before a bad update ran. It relies on two things: a base backup and an unbroken chain of transaction logs written after it. The engine replays those logs on top of the base backup up to the moment you pick.

On a self-run database, the team owns that chain end to end. First, someone decides where the logs go, how long they are kept and how the store is protected. Someone also checks that no log file is missing, since a gap limits the moments you can recover to.

In Signisys’s working view, the log chain can break during routine changes, such as a disk move or a new log location. It can then stay broken until someone notices. We recommend checking on a set rhythm that the chain is complete. A test recovery to a chosen time also belongs in the restore routine above.

The recovery point objective, or RPO, sets how far back the business will accept losing changes after an outage. Your log settings decide whether you can meet it in practice. The targets themselves come from a business decision on how much lost data and downtime the business accepts.

High Availability and Failover the Team Builds and Rehearses Itself

High availability means a database keeps serving users through the failure of one server or one component. Failover is the switch that makes this happen. A standby copy, called a replica, takes over as the main database when the primary fails. Disaster recovery covers the larger case. There, a whole site or system is lost, and the team restores service from backups or another location.

On a database you run yourself, the team builds and rehearses each part:

• setting up replicas and keeping them close to the primary;
• watching replication lag, the delay between a change on the primary and the same change on the replica;
• deciding who may promote a replica, and under what conditions;
• repointing applications, connection settings and scheduled jobs to the new primary;
• rebuilding the old primary as a replica once it returns.

Each of these steps can fail in its own way. For example, an application may hold the old address in a configuration file nobody remembered. A replica far behind the primary may lose recent changes when it takes over. Also, two servers can both act as primary if the promotion rules are loose.

We recommend a planned switch on a set rhythm, in a low-traffic period. Keep a written record of the time taken and what broke. For the line between the two ideas, see where staying up ends and recovery begins.

Out-of-Hours Monitoring and Night Alerts

A database needs watching at night as well as in the day. On a self-run database, that watching belongs to your team. The same holds on raw cloud virtual machines. There, the provider keeps the machine running, while the engine’s alerts still reach your staff.

The list of things to watch includes:

• disk and log space left on each server;
• replication lag on each replica;
• long-running locks and blocked queries;
• failed backup, maintenance and scheduled jobs;
• certificates and service account passwords close to expiry.

Collecting these signals is the easier half. Observability is the ability to understand what a system is doing from its logs, metrics and traces. It also helps the person paged at night move from the alert to the cause.

The harder half is deciding who gets paged, and for what. Give each alert an owner, a severity level and a first thing to look at. Alerts with none of these collect unread, and then a user reports the problem first.

Small teams feel this hardest. When two people share the on-call rotation, each one carries the pager for half the year. Leave and public holidays then need cover planned well ahead. We recommend a rotation wide enough that no one carries the pager for long stretches.

Capacity, Storage Growth and Hardware Lead Times

Data grows, and so do the transaction logs, indexes and backup copies that come with it. On a self-run database, someone tracks that growth and plans the next step before space runs out.

On premises, more capacity is a chain of events. The team raises a budget request, and the request waits for approval. The approved order then waits for hardware to arrive. After delivery, the new disks or servers need a maintenance window, and the database may need reconfiguring to use them. Each link in that chain has its own lead time. A growth spike does not wait for any of them.

Among self-managed database problems, capacity shortfalls tend to surface late, when a disk alert fires before anyone has placed the order. We recommend a growth forecast for each database, reviewed on a set rhythm. Write down the trigger point for a new order well before the disks fill.

The database also sits on shared storage and servers. For the storage side, see storage strain across the wider estate. For the servers underneath, see the hardware under the database aging out.

An estate built for nightly reporting can strain when the business asks for real-time dashboards or data for AI models. A separate article on our blog looks at that limit.

Hardening, Access Review and Audit Logs

On a self-run database, every security setting and every log is the team’s to produce. Nobody else configures the defaults, removes old accounts or answers an auditor’s request for records.

Hardening and Access Drift on a Database You Run

Hardening means closing the gaps a fresh install leaves open. On a database you run, the team checks each of these:

• default and sample accounts, removed or locked;
• network listeners, limited to the application servers that need them;
• encryption settings, for connections and for data on disk;
• admin rights, held by named people only.

Hardening at install time is only the start. Access drift is the slow return of those gaps after go-live. Staff leave, and their accounts stay. A contractor’s key keeps working after the contract ends. Service accounts gain rights during an urgent fix and keep them afterward. Shared admin logins spread because they are quick to hand out.

Among the database maintenance challenges a small team carries, access drift is easy to put off. Nothing breaks while it grows. The risk shows only when an old account is misused or an auditor asks who can reach the data.

We recommend an access review on a set rhythm. It needs a named owner, a list of each account and its rights, and a record of each removal. Tie the review to staff exits as well, so that a leaver’s access ends on their last day. Keep the review records alongside the restore records, where an auditor can find both.

Audit Logs and Sector Rules in India and the GCC

Auditors at regulated firms may ask how the database is run as well as what it holds. On a self-run database, your team produces those records. Requests can include:

• who accessed which data, and when;
• admin changes, such as new accounts, role changes and settings edits;
• how long logs are kept, and where they are stored;
• how the logs are protected from change.

In India, the CERT-In Directions dated 28 April 2022 say that logs of all ICT systems must be switched on and held securely for a rolling 180 days, inside India. The duty covers government organizations, service providers, intermediaries, data centers and body corporate. The Digital Personal Data Protection Act, 2023 asks whoever decides how personal data is used to put reasonable security safeguards in place so that a breach does not happen, a duty scheduled to take effect in May 2027. Firms that RBI or SEBI regulate should also check those regulators’ own directions. In the GCC, the UAE’s Federal Decree-Law No. 45 of 2021 applies to processing personal data through electronic systems, and Saudi Arabia’s Personal Data Protection Law applies to processing personal data about individuals in the Kingdom.

Where logs sit on separate servers in different formats, a person matches them by hand for each request. A central log store can turn that work into a report.

Self-Managed Database Problems When Knowledge Sits With One Person

A self-run estate can come to rest on one person. That person knows the replication set-up, the backup scripts and the order in which services restart after an outage. They also know which job fails at month end and why, and which application breaks if a setting changes. Much of this lives in their memory, or in scripts only they have read.

This kind of risk stays hidden while that person is at work. Leave, illness or a resignation then leaves a gap that no document fills. The next restore or failover falls to someone doing it for the first time, under pressure, at night.

We recommend a few habits that spread the knowledge:

• runbooks for each routine, written so a second engineer can follow them without help;
• a second person on every routine, taking turns with the first, so both stay in practice;
• rehearsals where the second person runs the restore or the failover while the first one watches.

For instance, a junior engineer could sit beside the database lead for each patch window. Then they run the next one from the runbook while the lead watches. Any steps the runbook left out get written in.

Time spent on upkeep is time the team does not spend on new work. Also, the more one person carries, the less room they have to hand over or build.

Signs Self-Managed Database Problems Now Outweigh Running It In-House

The balance tips away from running the database in-house when upkeep keeps pushing planned work aside and the gaps stay open. Six signs point that way.

Each sign on its own calls for an owner and a date. Several together, however, suggest the team spends its time keeping the lights on.

A managed service takes routine patching, backups and failover off the team. Even so, query design, schema changes and index work still need database skills in-house. A separate article, a look at running your own database against using a provider run service, compares the two models in detail. Another sets out the steps for moving a database.

In a consultation, a Signisys consultant goes through the eight burdens with you. Together you mark the ones your team holds today and pick those to address first. No charge, with a fixed scope.

A note on our interest: Signisys provides these services.

Scope of This Article and When to Call In Help

This article covers the upkeep of a database you run yourself. It leaves out the steps for moving a database, and scored checks before a move are set out in a scored set of checks to pass before a database moves. It also leaves out the comparison of managed and self-run models, product detail and tuning for any one engine.

Outside help makes sense in two cases. One is a regulated dataset, where an error in access or log keeping carries audit risk. The other is any production database with no tested restore. There, a failure today would test the backups for the first time.

If either applies, the use case page on moving your databases to a managed service explains the approach. For a wider estate, see planning and running the move as one program. You can also ask our cloud services team to review the database estate with you.

Self-Managed Database Problems: FAQ for IT Leaders