Backups for hotel systems: what to copy, where to keep it and how to test it

A hotel data backup is a second copy of the hotel's own records, kept somewhere the hotel can reach without the system that made them. Copy the PMS export, accounting, outlet sales, door-lock logs, shared files and email; keep three copies, one off site and one that ransomware cannot reach; test a restore every quarter.

The front desk is down at 08:40 on a Saturday and the manager is asked a simple question: when did we last copy this, and where is the copy? Most hotels can answer the first half and guess at the second. After reading this article you will have a written list of what to copy, a place to keep each copy that a failed disk or a ransomware infection cannot reach, a schedule with a named person behind it, and a quarterly test that proves the whole thing works.

What does a hotel still have to back up when the PMS runs in the cloud?#

Everything the cloud vendor does not hold. The vendor keeps the application and its database running; the hotel keeps the files, exports, contracts, outlet records and correspondence that live outside it, and often the only usable copy of its own history.

Separate two things plainly. The vendor's backup restores the vendor's system to a working state. The hotel's backup lets the hotel rebuild its own records if it changes system, loses access, or has to prove something to an accountant or a guest. These are different jobs, and only the second one travels with the hotel.

Walk the building and list where records are made: the PMS, the accounting program, the restaurant and bar tills, the spa booking book, the door-lock system's entry log, the shared drive, the reservation mailbox and the hotel's own website content. The door-lock database is easy to forget. It holds who entered which room and when, and it usually sits on one office computer with no copy at all.

Contracts, rate agreements with travel agencies, staff files and supplier invoices usually live in a shared folder that someone syncs to a personal account. That is not a hotel backup; it is a convenience copy tied to one person's login.

The honest test is a thought experiment: if the PMS vanished this afternoon, what could the hotel not rebuild? That list is the backup list. Write it down with a name next to each line. An unwritten list becomes one person's memory and leaves with that person. If you use multi-tenant software, it also helps to understand how each hotel's data stays apart in multi-tenant hotel software, so you know what the vendor holds and what only you hold.

The list: what to copy, and how to take the copy#

Copy the smallest set that lets the hotel trade again and prove what happened: PMS data, accounting, outlet sales, lock logs, contracts and shared files, and email. For each one, know the export, not just the folder.

For the PMS, ask the vendor for a full export in a format the hotel can open without that vendor: reservations, guest accounts, invoices and the guest database. A report pack is not an export; it is a printout of one view. For accounting, the copy is the program's own backup file plus the year-end declarations. The accountant usually holds these, so confirm in writing who copies them and where they are kept.

For outlets, copy the daily sales and till reports per outlet, not the whole terminal. The point is to be able to reconstruct a day's revenue. For door locks, export the entry log on a schedule and store it outside the lock system's own computer. For shared files, take a dated copy of the folder rather than relying on sync: sync copies a deletion as faithfully as it copies a file. For email, export the reservation and accounting mailboxes in a portable format; a mailbox that only exists in a web interface is not in the hotel's hands.

Name the person who takes each copy and the person who covers for them, and record the format and the date in one page kept with the contracts.

Where should the copies be kept?#

In three places, on two kinds of media, with one copy off site, and at least one copy that the hotel's own network cannot reach. That is the 3-2-1 idea, a common rule of thumb among IT teams rather than a formal standard.

On site, keep one copy on a separate device in the building, so a single failed computer is not a data loss. Off site, keep one copy physically elsewhere, or in a cloud account the hotel owns and controls, so fire, flood or theft does not take both.

The third copy is the one that matters most today: offline or write-once storage, disconnected when not in use. Ransomware encrypts every drive and synced folder it can reach from the infected machine. A USB drive left plugged in, a mapped network drive and a synced cloud folder are all reachable. Treat them as convenience copies, not as the safe copy.

Keep the off-site copy under the hotel's own account with its own credentials, not a staff member's personal account, and make sure two people can open it. Check that the off-site copy is a version history, not a mirror: a mirror reproduces the corruption or the deletion within minutes. Store the encryption key or password somewhere separate from the copies, in a sealed record held by two named people. A backup nobody can open is not a backup.

Backup placement is one part of the wider security picture; the rest is covered in the hotel cybersecurity checklist for owners and general managers.

How often should a hotel back up, and who confirms it ran?#

As often as the hotel can afford to redo the work, and always with a named person who checks that the job actually ran. A schedule without a check is a hope.

Set the frequency from one question per data set: if the system stopped now, how much work could we redo without real damage? A day of reservations is usually recoverable; a week is not. Match the schedule to how the data changes: outlet sales daily, PMS records nightly or better, contracts and rate agreements when they change, lock logs weekly.

Name a primary and a deputy, and give them a one-line check: open the backup log, confirm the last run's date and size, and sign it. Look at size, not only at the green tick. A job that reports success while copying almost nothing is a silent failure worth guarding against.

Have the general manager look at the log once a month, and record the review. This is the difference between a policy and a habit. Keep enough versions to cover the time before anyone notices a problem: corruption and quiet errors are often found weeks later, not the next morning. How long records must be kept is a question for the hotel's accountant and legal adviser, not for a software vendor or an article; set the backup schedule to satisfy that answer, not to guess at it. Access to the systems involved is its own topic, covered in the PMS user roles and permissions setup checklist.

How do you test a backup restore?#

Restore it somewhere that is not the live system, open it, count what is inside and time how long it took. Do this once a quarter and write the result down.

Restore to a spare computer or a separate folder, never over live data; the test must not be able to damage the working system. Open real files, not just the folder: one reservation, one guest account, one invoice, one contract, one till report. Count something, such as the number of reservations in a chosen week, and compare it with the live system.

Time the whole restore from start to usable, and write the number down; that figure is what the hotel will live with on the day. Test the copy that is hardest to reach, meaning the off-site or offline one, because that is the copy that will be used in a real incident. Record what failed and fix it before the next quarter. A test that finds nothing wrong twice in a row usually means the test is too easy.

Keep the test records. Insurers, auditors and, in a dispute, a guest or an agency may ask how the hotel protects its records.

What should you ask a cloud vendor about backups and getting your data out?#

Ask how often they copy, how long they keep it, how fast they restore, and whether the hotel can export its own data without asking them. Get the answers in the contract, then test the export.

Ask about frequency and retention: how often is the vendor's copy taken, how many versions are kept, and can the hotel ask for a specific day. Ask about restore time: how long from request to a working system, and who is allowed to request it at 02:00 on a Sunday. Ask about separation: are the backups held apart from the live system, so that one failure or one compromised account does not take both.

Ask about export: is there a self-service export of reservations, guest accounts, invoices and the guest database, in a format the hotel can open without the vendor, and how often may it be run. Ask about exit: what happens to the data at the end of the contract, how long it stays available, and what the hotel receives.

Do not accept a verbal answer. Run the export yourself once, open the files and note the date; a promise about data portability is worth what the test shows. The same questions apply to the accounting program, the door-lock system and the till software, which are often cloud services too.

When the export does work, the next question is what to carry across, covered in PMS data migration: what to move, check and leave behind.

What to do next#

Pick one data set this month, name the person who copies it, and restore it once to a machine that is not the live system. That single test turns the rest of this article into a routine: the list grows from what the hotel could not rebuild, the schedule follows what the hotel can afford to redo, and the quarterly restore is the only proof that any of it works.