Hotel CCTV systems: calculating recording time, camera count and storage

A hotel CCTV system is sized in this order: zones and purpose first, then camera count, then retention days, then storage. Storage is bitrate multiplied by time: one camera at 1 Mbps writes about 10.8 GB a day. No fixed retention period applies to every hotel, so agree yours with your legal adviser.

The request usually arrives on a Monday: a guest's lawyer, an insurer or the police want footage from a corridor three weeks ago. The screen shows live pictures, the recorder light is green, and nobody in the building knows whether that night was actually recorded, or whether the clock burned into the picture is right. This guide gives you the working method: how to arrive at a camera count from the job of each zone, how to calculate storage from bitrate, what installers routinely skip, and how to prove every month that the recordings are really there.

How many cameras does a hotel need?#

The count falls out of the zones, not the other way round. List what each area has to prove after an incident, then place a camera that can prove it, and the number appears on its own.

Write one line per zone: what happened here that I may need to show later. A car park needs plates and approach, a lobby needs who crossed the floor and when, a loading bay needs what left the building. If you cannot finish the sentence, the camera there is decoration.

Separate two jobs that need different cameras. An overview camera shows movement across a space; an identification camera shows a face or a plate at a known point. One camera rarely does both well, and pretending otherwise is how corridors end up with footage too coarse to identify anyone.

The standard zone list for a hotel covers: vehicle entrance and car park, main entrance and lobby, reception desk, corridors and lift lobbies, back of house (stores, loading bay, cash office, staff entrance), pool, spa and gym, and perimeter and roof access. Guest rooms, bathrooms and changing areas are out, and so is anything that reads a screen showing guest data, a key rack or a payment terminal keypad.

Overlap the edges. A camera that ends exactly where the next one begins leaves a gap at the stairwell, which is where incidents tend to happen. And placement and notices are a legal question as much as a technical one: work through the checklist for notices, placement and footage handling under Türkiye's personal data law before the installer drills anything.

IP or analogue, and what is an NVR?#

An NVR is a recorder that stores video arriving from network cameras over a cable; a DVR stores video from older analogue cameras on coax. Both keep the pictures and let you find them again, and the difference is what the cable carries.

An IP camera is a small computer with a lens and a network address. It sends a video stream, so it needs a network switch and a configuration, not just a video cable. Power over Ethernet (PoE) carries power and data on one cable, which is why an IP installation is really a network project with cameras on the end of it.

Analogue cameras on existing coax are usually the cheaper path in a renovation where the cabling is sound and the resolution is enough. IP wins where you need detail at distance, more cameras per cable run, or one place to manage accounts. Hybrid recorders accept both, which is a reasonable way to keep old cameras while new zones go IP, but the recorder's channel count and disk bays then become the limit on everything.

Ask for the recorder's channel count with spare channels, its disk bays, whether it supports a redundant disk set, and whether the cameras can also record to a card inside themselves if the recorder dies. The codec matters more than the brochure suggests: a newer compression standard can cut the bitrate substantially at the same picture quality, but the cameras and the recorder must support the same one, or the recorder falls back to the older, heavier stream.

If the building is new, the cabling and conduit decisions come before the walls close and cost far more to change afterwards; the same applies to every low-voltage system in a new hotel.

How do you calculate recording time and storage?#

Storage is bitrate multiplied by time. One camera at 1 Mbps writes about 10.8 GB a day, so multiply its real bitrate by the number of cameras and by the days you keep, then add headroom.

The constant comes from the arithmetic, not from a vendor: 86,400 seconds in a day, divided by 8 bits in a byte, gives 10.8 GB per day for every 1 Mbps of stream, counting 1 GB as 1,000 MB. Bitrate is set by resolution, frames per second, how much moves in the scene and which codec is used. A corridor at night is cheap; a windy car park with trees is expensive.

Do not guess the bitrate from the resolution alone. Take it from the camera's specification sheet, or record one camera for a day and read the real figure off the recorder. The measured number is the one to put in the tender.

Continuous recording is predictable and easy to defend. Motion-triggered recording saves disk but can miss the seconds before the movement, which are often the seconds that matter.

Add 10 to 20 percent headroom for the recorder's file system, its index and the difference between the disk's advertised size and its usable size. If the disks run in a redundant set, one disk's capacity is spent on protection. Then run the calculation backwards: with the disks you already own, how many days do you actually get at the bitrate you chose? That number, not the brochure, is your retention.

The table below is a worked example, not a recommendation. Your bitrates, camera count and days will differ.

For example, these 24 cameras write about 572 GB a day; 30 days of retention needs about 17.2 TB, and adding 15 percent headroom gives about 19.7 TB of usable storage to buy.

Should you set the retention period before the disk size?#

Yes. Retention is a decision about duty and risk, and disk size is arithmetic that follows it. Choosing disks first means the retention period is set by accident, by whoever sized the box.

This article states no legal retention period, because none is established here as a single rule. Agree the period with your legal adviser, in writing, and record why you chose it. Retention is not one number for the whole building: a cash office, a loading bay and a main entrance usually justify a longer period than a corridor, and a per-zone table is easier to defend than a single figure.

Keeping footage longer than you need is a personal-data risk, not a safety margin. More disk is not automatically the conservative choice. Write the retention per zone into the tender, then let the installer prove the disks meet the longest one at the bitrate you specified.

The same discipline you use for other guest records applies here: decide the period, the owner and the destruction step, and review it once a year or when the system changes. The method is the same one described for building a retention and destruction table for guest records.

What do installers skip?#

Four things, consistently: the network, the passwords, the remote access and the power. None of them show up on a live-view demonstration, and all of them decide whether the system is still useful in a year.

A shared network is the most common mistake. Cameras belong on their own segment, so a guest streaming video cannot starve the recorder and a compromised camera cannot reach the front desk system. The same logic drives the wider rule of separating guests, staff, payments and devices on the hotel network.

Default passwords survive handover because nobody writes down who changed what. Every device needs its own credentials, an admin account that is not shared with staff, and a named owner for firmware updates. Remote viewing is usually enabled by forwarding a port on the router, which puts the recorder on the public internet; a private connection or the vendor's cloud service with named accounts and a second factor is the safer pattern.

Power during a cut is forgotten until the first outage. The recorder and the switches that feed the cameras need a battery unit sized for a clean shutdown, and someone must confirm afterwards that recording resumed by itself. Time sync is invisible until it matters: if the camera clock drifts from the front desk system and the door logs, matching an incident across three sources becomes guesswork.

Ask at handover who holds the admin password, where the camera map is kept, and what happens to the accounts when the installer's contract ends.

How do you check every month that recordings are really there?#

Play back an old minute from a camera you did not choose, compare the clock with a known time, and export a clip. It takes about ten minutes, once a month, and it is the only proof you have.

Live view proves the camera works, not that anything is being written. The two failures look identical on a monitor. Pick a date at random from two or three weeks back and a camera at random from the list, and play a minute; if the recorder has quietly stopped writing to one channel, this is how you find it.

Check the oldest footage on the system against the retention you agreed. If the oldest clip is nine days old and you asked for thirty, the disks or the bitrate are wrong. Export a clip and play it on a machine that is not the recorder, using the player the recipient will actually have; an export that only opens on the recorder is not an export. Read the recorder's disk health screen and clear the warning that has been sitting there since spring.

Write the result down: date, camera, minute played, clock difference, export result, initials. A log turns a claim into a record.

What should the tender and the acceptance test specify?#

Write the outcome, not the box: which zones, which retention per zone, which bitrate, which accounts, and how you will prove all of it on handover.

A camera schedule per zone, with the job of each camera written next to it, makes a cheaper substitute visibly a change and not a detail. Retention per zone and the bitrate assumed for each zone let the storage figure be checked rather than trusted. Network separation, the account list, password handover and the removal of the installer's own admin account all belong as contractual lines rather than good intentions.

An acceptance test with a date: on day thirty, the installer plays back a random minute from every camera in front of you, and exports one clip. Ask also for as-built drawings, the camera map and the address list, because the next technician will not be the one who installed it. And write down what happens at the end of the contract: who owns the footage, who deletes it, and how you get a copy before the equipment leaves.

What to do next#

Before you call an installer, write the one-page zone table: each zone, what it has to prove, the camera job, and the retention you agreed with your legal adviser. That page is your specification, and every conversation that follows, from camera count to disk size, becomes arithmetic against it rather than a negotiation about boxes.