Recovery terms for hotel systems: RTO, RPO, backup, failover and what they mean at the desk

RTO (recovery time objective) is the longest a hotel accepts being without its system; RPO (recovery point objective) is how much recent work it accepts losing. Both are targets the hotel sets, not promises from a vendor, and both only mean something when a test restore and a written outage procedure back them up.

For example, the contract says four hours and fifteen minutes. It is 23:40 on a full night, there is a queue at the desk, and nobody on the team can say whether that means four hours of paper check-ins or four hours of a slow system, or whether fifteen minutes is one posting or forty. This article translates RTO, RPO, backup, replication and failover into desk language, and ends with the questions to put in writing before signing.

What do RTO and RPO mean at the front desk?#

RTO is the longest the hotel accepts being without the system; RPO is how much of the most recent work it accepts losing. Both are objectives the hotel sets and the provider must meet, not features of the software.

RTO ends when the desk can check in a guest, post a charge and close the day, not when a server answers again. A provider whose monitoring shows the machine back in twenty minutes has not met a two-hour RTO if the team is still working on paper. Agree what starts and stops the clock: the hotel noticing, the hotel reporting and the provider confirming are three different moments, and the gap between them is often longer than the recovery itself.

RPO in time is only half the definition. Convert it into work. A fifteen-minute RPO at peak checkout covers the postings of the last fifteen minutes, which may include cash taken and signed bills the system cannot reconstruct. Cash cannot be re-entered, only matched against paper.

Both numbers are per scenario. A failed disk, a corrupted database, a record deleted by mistake, a lost internet line and a power cut have different realistic times. One pair of numbers covering all of them is a marketing number. Separate the objective from the outcome: the objective is what was agreed, the actual recovery is what happened on the night. Ask how both are recorded and who sees the record.

The hotel decides what it can tolerate; the provider states what it can deliver and at what cost. No number should be accepted because it looks small.

What is the difference between backup, replication and failover?#

A backup is a copy kept to restore from later, replication is a copy kept continuously up to date, and failover is the act of switching work to a second running system.

A backup is a point-in-time copy, usually stored apart from the live system. It is slow to use, and that restore time is a large part of the RTO. Replication copies changes as they happen: if it lags, the lag is the real RPO; if it is synchronous, it costs speed on every transaction the desk makes. Failover switches work to a standby system, automatically or by hand, and shortens the RTO, but only for the failures it was built for.

Two distinctions matter most. A replica is not a backup: a wrong deletion or a bad import is copied to the replica within seconds, while a backup taken before the event still exists. And failover does not repair data that was already corrupted before the switch; the standby may simply hold the same bad records. For more on the copy itself, see backups for hotel systems: what to copy, where to keep it and how to test it.

Match the term to the failure you actually fear: hardware failure, a lost internet line, a whole region out, human error, or someone locking the hotel's files and demanding payment.

What is a test restore, and why ask for the date of the last one?#

A test restore is a rehearsal in which the provider rebuilds the system from a copy and proves it works. Without one, a backup is a claim rather than a capability.

A real test restores into a separate environment, opens a named reservation, runs the night audit, checks that the e-invoice queue and the channel updates behave, and times the whole exercise. "Backup completed" and "restore succeeded" are different statements; a provider may report the first and never the second. The measured restore time is the honest input for the RTO. The planned time is not.

A restore that worked a year ago proves little about tonight's data volume and tonight's software version. A named person at the hotel should see the result, not only the provider's status page.

Ask for the date, the scenario and the result in writing, and keep that answer with the contract.

What does each target look like at checkout hour?#

At checkout hour the numbers stop being technical and become a queue of guests, a stack of paper and a list of charges to re-enter.

With a short RTO, minutes mean a pause and a growing queue; an hour means paper check-in forms, manual key encoding if the lock system is separate, and a KBS (guest identity notification) backlog to clear later. With a long RTO, a whole shift runs on paper, someone must decide about turning walk-ins away, and the reconciliation job grows with every hour.

For RPO, count the postings in a peak hour: restaurant, bar, minibar and late checkout. That count is what may need re-entering, and cash taken cannot be re-entered at all, only matched against the paper. The trade-off is real: a very short RTO usually comes with a longer RPO or a higher cost, and a very short RPO usually lengthens the RTO. Ask which one the hotel actually needs at 23:00.

Channels keep selling during the gap. When the system returns, the first job is checking for bookings taken elsewhere while availability was not being updated. The broader desk procedure is covered in when the internet goes down: a front desk checklist for cloud-based hotels.

Run the card test. Write the two targets on a card, hand it to the night manager, and ask what they would do. A vague answer means the numbers are decoration.

Which questions should a hotel put in writing before signing?#

Ask for the scenario, the clock, the last test restore and the treatment of work in flight, and ask for the answers as defined terms in the contract rather than as slides.

The most important questions are about boundaries, not headline numbers. What exactly starts and stops the recovery clock, and who is allowed to declare an outage. Which failure scenarios the numbers cover, and which are excluded in the small print. What happens to work in flight: reservations held but not confirmed, channel availability, e-invoices waiting for a person's review, and messages queued to guests.

Ask who the hotel calls at 03:00, by name and number, and what that person can decide without escalating. Ask whether the targets differ between cloud and on-premise, and who is responsible for each part of the chain; the split matters more than the headline number. For that decision itself, see cloud or on-premise hotel software: weighing the trade-offs.

How do recovery targets connect to the outage procedure?#

The targets set how long the paper procedure must last and how much of it must be reconcilable afterwards. Without that procedure they describe a system, not a hotel.

State the RTO in desk terms inside the procedure: how long the team works on paper before the decision is escalated to the general manager. Capture everything the RPO will need: a numbered paper log of check-ins, charges, cash taken and authorizations, kept in time order.

On return, reconcile. Compare the paper log to the system, look for double postings and missing charges, and check channel availability for bookings taken during the gap. Agree who pauses and reopens sales on other channels while the system is down, and where that decision is recorded.

Then rehearse the procedure once with the targets in hand, time it, and correct either the numbers or the procedure, whichever was wrong. Review after every real outage and every test, and keep the contract terms and the desk procedure in step. If the failure you fear is power rather than the network, pair this with power cut at the hotel: a checklist for the first hour and the generator.

What to do next#

Write the two numbers on one card and the desk procedure on another, then make them agree. The single next step is to ask your provider, in writing, for the date and result of the last test restore. That answer tells you whether the numbers on the card describe anything real.