Cameras multiplied by bitrate multiplied by hours: the storage calculation set out step by step, with worked examples you can redo using your own recorder’s settings.

Every recorder is doing the same simple thing: writing a stream of data to a disk until the disk is full, then writing over the oldest footage. So how many days you keep is not a setting you can turn up. It is arithmetic:
Days of footage = drive capacity (GB) × 0.9 ÷ (number of cameras × bitrate in Mbps × hours recorded per day × 0.45)
That 0.45 is just unit conversion, and it is worth seeing where it comes from rather than trusting it. One megabit per second is 1,000,000 bits every second. Divide by 8 to get bytes: 125,000 bytes per second. Multiply by 3,600 seconds to get an hour: 450 MB per hour, per megabit per second. In other words 1 Mbps = 0.45 GB per hour = 10.8 GB per day, per camera.
Anyone who tells you “this system records 30 days” without asking how many cameras, at what bitrate, and recording for how many hours a day, is telling you nothing. The whole calculation is above; the rest of this page is about getting each input right and what to do with the answer.
This is the number people guess, and it is the only one that really matters. Do not use a figure from a web page, including this one. Your recorder knows its own setting and will show it to you.
On almost every DVR or NVR the path is similar: the recording or encoding settings page, per channel, where you will find a stream type (main stream and sub stream), a resolution, a frame rate, a bitrate type and a bitrate in Kbps or Mbps. The main stream is the one being recorded; the sub stream is the low-quality copy used for phone viewing and takes a small fraction of the space. If the bitrate is shown in Kbps, divide by 1,000: 4,096 Kbps is 4 Mbps (recorders use 1,024 to the megabit).
Two things to note while you are in there. If the bitrate type is constant, the camera writes that number all day and the arithmetic below is exact. If it is variable, the figure shown is a ceiling and the real average depends on how much movement the scene contains — a camera watching a quiet corridor will write far less than one pointed at a busy road with trees moving behind it. With variable bitrate, treat the calculation as a worst case, which is the right way round for planning.
Take the bitrate you just read and find it here. These are conversions of the formula above, not claims about what any system is set to — substitute your own number:
| Bitrate (per camera, main stream) | Per camera, per day | Per camera, over 30 days |
|---|---|---|
| 1 Mbps | 10.8 GB | 324.0 GB |
| 2 Mbps | 21.6 GB | 648.0 GB |
| 4 Mbps | 43.2 GB | 1,296.0 GB |
| 6 Mbps | 64.8 GB | 1,944.0 GB |
| 8 Mbps | 86.4 GB | 2,592.0 GB |
Send us a photo of the job on WhatsApp — we reply with an instant quote.
💬 Get Your Instant QuoteIf your bitrate is not in the table, multiply it by 10.8 for the daily figure. A camera set to 3 Mbps writes 32.4 GB a day; one set to 5 Mbps writes 54.0 GB.
Now multiply by the number of cameras recording, and divide the drive capacity by the result. This table does that for continuous 24-hour recording on a 2TB and a 4TB drive, using 2,000 GB and 4,000 GB as the drive-maker’s capacity and keeping 10 per cent back as usable-space reserve:
| Cameras | Bitrate each | Written per day | On a 2TB drive | On a 4TB drive |
|---|---|---|---|---|
| 4 cameras | 2 Mbps | 86.4 GB | 20.8 days | 41.7 days |
| 4 cameras | 4 Mbps | 172.8 GB | 10.4 days | 20.8 days |
| 4 cameras | 8 Mbps | 345.6 GB | 5.2 days | 10.4 days |
| 8 cameras | 2 Mbps | 172.8 GB | 10.4 days | 20.8 days |
| 8 cameras | 4 Mbps | 345.6 GB | 5.2 days | 10.4 days |
| 8 cameras | 8 Mbps | 691.2 GB | 2.6 days | 5.2 days |
| 16 cameras | 2 Mbps | 345.6 GB | 5.2 days | 10.4 days |
| 16 cameras | 4 Mbps | 691.2 GB | 2.6 days | 5.2 days |
| 16 cameras | 8 Mbps | 1,382.4 GB | 1.3 days | 2.6 days |
Read the bottom rows before you accept a 16-camera quote with a free drive in it. Sixteen cameras at 8 Mbps — not an unusual setting once somebody specifies 4K across the board — fill a 2TB drive in 1.3 days. That is not a fault. It is what the arithmetic says, and it is why the drive line on a quote deserves as much attention as the camera line.
A typical Klang Valley shoplot: eight cameras, main stream set to 4 Mbps, recording continuously, on the 2TB drive that came with the package.
Every step there is arithmetic you can redo with your own bitrate and camera count in about a minute. Do it before you sign, not after the incident.
The easiest way to buy more days without buying a bigger drive is to record less of the day — and the honest way to model it is as a fraction that you choose, not a percentage anyone can quote you.
If a camera records only 8 of the 24 hours, it writes one third of the data and you get three times the days. If it records 12 hours, half the data and twice the days. Substituting your own fraction into the formula is the whole method.
| Recording pattern | Multiplier on storage | What you should know |
|---|---|---|
| Continuous, 24 hours | × 1 | Nothing is missed and nothing has to trigger correctly. The baseline every calculation on this page uses |
| Schedule, e.g. 12 hours overnight | × 0.5 | Predictable and safe if the risk really is confined to those hours. Whatever happens outside the window does not exist |
| Motion-triggered only | You choose the fraction | Depends entirely on the scene — a quiet store room records almost nothing, a camera facing a road records nearly continuously |
| Continuous at low rate, higher on motion | Between the two | Often the best compromise: you always have a timeline, with detail where something moved |
Two warnings about motion recording. It needs pre-record and post-record buffers set, or clips start after the event; and false triggers — rain, moving foliage, a spider on the lens at night, headlights — can turn “motion only” into “continuous with gaps”, which is the worst of both. If footage genuinely matters, continuous recording on a drive sized for it is the more reliable engineering choice.
Compression is the other lever. H.265 is a later codec than H.264 and is designed to deliver comparable picture quality at a lower bitrate; how much lower depends on the scene and the encoder, so the honest way to use it is not to apply a percentage but to switch it on and read the new bitrate off the recorder — then rerun the arithmetic with that figure.
Three practical points. The camera and the recorder both have to support the codec, so it is a system decision rather than a checkbox. Older phones, browsers and third-party software sometimes struggle to play H.265 exports, which matters on the day you have to hand a clip to somebody else. And some manufacturers ship a further “smart” variant that lowers the bitrate on static parts of the scene — useful, but check what it does to detail on the part of the frame you actually care about before trusting it.
Bitrate is not chosen in a vacuum. It follows from what you have asked the camera to do:
Two adjustments make the tables above a ceiling rather than a promise, and both are worth knowing before you are disappointed.
First, drive makers count a terabyte as 1,000,000,000,000 bytes while an operating system counts in powers of two, so a “2TB” drive is reported by most software as roughly 1.82TB. The tables here use the drive maker’s figure — 2,000 GB and 4,000 GB — because that is what is printed on the box, so if your recorder shows a smaller number, that is why.
Second, a recorder does not use every last byte: it reserves space for its own database and index, and it begins overwriting before the disk is literally full. So take the calculated figure as an upper bound and give yourself margin rather than sizing a drive to exactly the days you need.
The practical version of both points: if you need a fortnight of footage, do not buy the drive that calculates to exactly fourteen days.
A CCTV recorder writes continuously, every second, for years — a duty cycle an ordinary desktop drive is not built for. Surveillance drives (the purple and hawk-branded families) are specified for continuous writing and for several drives sitting in one chassis. Malaysian marketplace prices for them look like this. These are retail shelf prices for a product, shown as floors because the listing spread is enormous, and they are not part of any installation cost:
| Hardware | Typical Malaysian retail price | What it is |
|---|---|---|
| 1TB surveillance hard disk | from RM326 per drive | 1TB stock is thin, so it often lists above a 2TB drive — check both before you buy |
| 2TB surveillance hard disk | from RM234 per drive | continuous-write drive (WD Purple / Seagate SkyHawk); a desktop drive voids the warranty |
| 4TB surveillance hard disk | from RM420 per drive | what you need once you want a month of footage rather than a week |
One oddity in those rows is worth flagging rather than hiding: the 1TB floor sits above the 2TB floor, because 1TB stock is thin and the listings are strange. So do not draw a neat price-per-terabyte curve through these three numbers — check the current listings for both capacities before buying, and expect the larger drive to be the better value more often than not.
Other practical points: check the maximum drive capacity your recorder supports before buying a large disk, and check how many bays it has. Fitting a desktop drive to save money is a false economy that usually ends with a drive failure and no footage from the period you needed.
There is no rule we can hand you here, and any page that states one as a general legal requirement is overreaching. It is a business and engineering judgement, and the useful way to make it is to ask how long it realistically takes for somebody to notice that something happened:
Set the target from the longest of those that applies to you, then size the drive from the arithmetic. And keep in mind the reverse point: footage you never need is footage you are storing about people, so retaining far more than you have a reason to is not a free choice either. Sizing deliberately is better than sizing by accident in both directions.
The rest of the lines a comparable CCTV quote should carry are on what CCTV installation costs in the Klang Valley, and the items most often left off a cheap package are on the “free installation” page.
You do not have to trust anybody’s calculation, including this one. Once the system has been running long enough to have overwritten once, open the playback calendar and find the earliest date that still has footage. The gap between that date and today is your real retention, measured rather than modelled.
Make it a habit: check it monthly, along with two other things worth thirty seconds each — that every camera is still online, and that the picture on each is not obscured by a web, dust or condensation. Cameras fail quietly, and a system nobody checks is a system that will turn out to have been broken since the last storm.
If the measured retention is much shorter than the calculation, the usual causes are a higher real bitrate than the setting suggested, cameras recording continuously when you thought they were on a schedule, or a sub stream also being recorded. All three are visible in the recorder’s own settings.
Storage is one of the few parts of a CCTV job that can be settled on paper before anyone visits — but only once the camera count, the positions and the resolution each position needs are settled, and those come out of the survey. ClickBina does not publish a package price for CCTV, because the cabling route decides the job; what we will do is tell you what recording days your proposed system gives before you agree to it, and size the drive to the answer you actually want.
Send photographs of the positions you want covered and where the recorder will live, and we will come back with the specification and the arithmetic behind it. See the rest of our electrical and plumbing services, or compare the two system types first on IP versus analog CCTV.
Tell us what you need — we reply within the hour.