For a 24/7 channel, estimate storage from the bitrate of the local recording and how long you plan to keep it. At a constant bitrate, each 1 Mbps needs about 10.8 decimal GB per day, or 3.94 decimal TB over 365 days, before overhead and safety margin.
Those figures are arithmetic estimates, not measured file sizes. The examples below use YouTube’s H.264 live-ingest recommendations as useful reference points; your own recording settings, variable bitrate and retention plan determine what capacity you actually need.
The short answer: bitrate and retention set capacity
A 24/7 archive grows continuously. Resolution alone does not tell you how much storage to buy: two recordings at the same resolution can have different bitrates, and a local recording can use different settings from the stream sent to YouTube. The key input is the local file’s average bitrate, followed by the number of hours or days you keep it.
A single day at 1 Mbps is roughly 10.8 GB in decimal units. Multiply that baseline by your recording bitrate, then by the number of days retained. For example, a constant 10 Mbps recording retained for 30 days is approximately 3.24 TB: 10.8 GB × 10 × 30. That is an estimate, not a promise about the file system’s reported size.
Retention changes the answer as much as the quality setting. A channel that keeps only the latest week needs much less working capacity than one preserving a year of every stream. If you also keep a second copy, count it separately: two copies of the same archive roughly double the storage requirement before accounting for overhead.
Use a bitrate-times-hours estimate
For a constant bitrate, the reusable formula is:
Decimal GB ≈ bitrate in Mbps × hours × 0.45
The factor converts megabits per second across the stated number of hours into decimal gigabytes. In practical units, calculate the stream’s bitrate multiplied by the hours recorded, then multiply by 0.45. For a daily estimate, use 24 hours; for a monthly estimate, use the hours in the period you intend to retain rather than assuming a particular month length.
For example, suppose your local gaming recording averages 8 Mbps and you retain 72 hours of footage. The arithmetic estimate is 8 × 72 × 0.45, or about 259 GB. It represents the video and audio data implied by the bitrate and time. It does not include filesystem overhead, any safety margin, multiple copies, or extra tracks that may affect the actual files.
Use the local recording bitrate as the input when estimating local disk use. If you record the same encoded stream that you send live, the live bitrate is a reasonable approximation. If your recording software uses a separate quality or bitrate setting, use that setting instead. YouTube’s live guidance and its upload encoding guidance are different tables, so do not substitute an upload recommendation for a live or local-recording bitrate without checking that it matches your workflow.
A variable-bitrate or quality-based recording complicates the arithmetic because the data rate changes with the gameplay. A busy scene with movement and effects may produce a different file size from a static menu, even with the same recording profile. In that case, record a representative session using the intended settings, check its size and duration, and scale that observation to your retention period. This measurement is more useful for buying storage than treating a nominal target as a fixed file size.
Estimate daily, monthly and yearly storage
For 24/7 recording, multiplying the 1 Mbps baseline by 24 hours gives about 10.8 decimal GB per day. Over 365 days, the same constant bitrate works out to about 3.94 decimal TB. Multiply these figures by your local recording bitrate to estimate a full year, or by the days you want to retain for a shorter window.
| Local recording bitrate | Approximate per day | Approximate per 365-day year |
|---|---|---|
| 1 Mbps | 10.8 GB | 3.94 TB |
| 5 Mbps | 54 GB | 19.7 TB |
| 10 Mbps | 108 GB | 39.4 TB |
| 20 Mbps | 216 GB | 78.8 TB |
These values use decimal units: 1 TB is 1,000 GB. Drive operating systems and storage vendors may display capacity using different unit conventions, so a displayed number may not line up exactly with the decimal estimate. Also, a nominal disk capacity is not necessarily the usable space available for an archive, especially if the storage is configured with redundancy or reserved space.
For a retention window shorter than a year, scale by the actual number of days. At 10 Mbps, 30 days is approximately 3.24 TB by the daily estimate; seven days is approximately 756 GB. These are still arithmetic estimates. The actual file set may be larger or smaller depending on average bitrate and file structure, and you should not plan to fill every byte of a disk.
If you segment the broadcast into separate files or sessions, the total data rate does not change the basic estimate, but each file can have its own small amount of container and filesystem overhead. The effect is not captured by the bitrate calculation. Keep the distinction clear when comparing the estimate with a test recording or a drive’s available space.
Compare YouTube’s supplied 1080p60, 1440p60 and 4K60 examples
YouTube’s live encoder guidance gives recommended H.264 ingest rates that can serve as reference examples. The following annual and daily figures apply the same bitrate-times-hours arithmetic to those rates; they are not measurements of finished VOD files.
| H.264 live output example | YouTube recommended live bitrate | Approximate storage per day | Approximate storage per 365-day year |
|---|---|---|---|
| 1080p60 | 17 Mbps | 184 GB | 67 TB |
| 1440p60 | 34 Mbps | 367 GB | 134 TB |
| 2160p/4K60 | 50 Mbps | 540 GB | 197 TB |
The calculation is direct: 17 Mbps × 24 hours × 0.45 is approximately 184 GB per day; multiplying the bitrate by 3.94 TB per year for each Mbps gives about 67 TB annually. The same method gives approximately 367 GB daily and 134 TB annually at 34 Mbps, and 540 GB daily and 197 TB annually at 50 Mbps. Rounding accounts for the displayed figures.
These examples help show the effect of bitrate, not the effect of resolution by itself. If you record locally at a different quality setting, use that local setting rather than assuming it matches YouTube’s recommendation. YouTube lists distinct rates for other codecs, so the H.264 figures above should not be applied as though they were codec-independent.
YouTube also publishes separate upload encoding recommendations. They describe a different workflow from live ingest. For storage planning, the encoding table matters only if its settings correspond to the file you are actually creating; otherwise it can lead you to estimate the wrong bitrate. If you are building a prerecorded playlist rather than archiving a live gaming channel, the workflow differs too; see this guide to streaming a video playlist with OBS.
Add overhead and leave a safety margin
The formula estimates the payload from bitrate and elapsed time. It explicitly excludes filesystem overhead and safety margin, so do not treat the output as the capacity to buy. Actual recordings include container and file-system details the simple calculation does not model. Variable-rate recording can shift the total in either direction from a nominal bitrate estimate.
There is no universal margin that suits every setup. Instead, reserve headroom based on how the archive is organised, how much space the recording system needs for temporary files, and how much the bitrate varies. Avoid designing a plan that leaves the disk nearly full after the estimated archive is copied. A sample recording made with your intended settings is the practical check: compare its measured duration and file size with the arithmetic estimate, then choose capacity that leaves room for growth and ordinary file-management work.
Count audio and alternate versions consciously. If you record additional audio tracks, retain both a clean recording and a stream-ready version, or export edited copies, those files occupy space beyond a single-copy estimate. Likewise, a backup copy is not free capacity: if you keep two complete copies, calculate for two archives. The safest planning unit is usable capacity after any storage redundancy, not the headline capacity printed on a drive.
For a physical purchase, compare usable capacity, cost per usable terabyte, expansion options, and what happens if a drive fails. A single large drive may be simpler, while a redundant arrangement can preserve access after a failure but reduces available archive space. Keep a separate recovery plan for material that cannot be recreated; storage hardware alone does not make an archive protected.
Plan a retention window for gaming VODs
Start by deciding what the archive is for. If you only need recent sessions to make clips, a short rolling window may be enough. If viewers need to revisit past broadcasts, or you want to compare gameplay over time, a longer window has value, but it multiplies the storage requirement directly. Choose the retention duration before choosing capacity rather than buying a disk and discovering later that it holds less history than expected.
Write down three numbers: local recording bitrate, days retained, and number of copies. Use the daily estimate for the first two, then multiply for the copies. For instance, at 17 Mbps, the supplied example is about 184 GB per day. A 14-day archive is therefore about 2.6 TB for one copy by simple arithmetic, with overhead and headroom still to add. If you want two copies, budget for roughly twice the archive data before those additions.
YouTube’s archive live streams help page says automatic archiving applies to streams under 12 hours and warns that a stream exceeding 12 hours may not be captured at all. It recommends keeping a local archive as a backup. A continuous 24/7 broadcast should not be treated as a guaranteed complete platform VOD; if a complete history matters, make a local capture plan or organise deliberate sessions and verify the resulting archives.
This issue is about capture as well as capacity. If you stream prerecorded material, the continuous prerecorded 4K guide discusses the distinct question of sending files continuously. For a local archive, however, count the recording that your workflow actually produces. A YouTube replay, a local capture and an uploaded source file are not interchangeable copies unless you have verified that each contains the material and quality you need.
For gaming, decide how often older footage can be deleted, moved to slower storage, or preserved selectively. You might keep recent sessions readily available for editing and retain only chosen highlights for longer. That trades convenience against management effort: selective retention saves space but requires a consistent review process, while keeping everything simplifies decisions and raises capacity needs. If the channel also runs non-gaming material, such as a looping exam-prep lecture playlist, do not assume its bitrate or retention needs match gaming footage.
A local archive also needs an owner. Decide who checks free space, verifies that recordings are being created, and removes or moves files when the retention limit is reached. An unattended recording can quietly stop when a disk fills, so capacity planning should include a routine check rather than relying on a one-time purchase. Keep the archive separate from the only working copy of any source footage you cannot reproduce.
Turn the estimate into a storage plan
Use the formula to narrow the decision, then validate it. First, find the local recording bitrate or create a representative sample with the exact recording settings. Second, calculate daily and retained-period volume. Third, count additional versions and copies. Finally, add suitable headroom and compare that requirement with usable, not nominal, capacity.
For example, a channel recording at the 34 Mbps reference rate and keeping 30 days has an arithmetic estimate of roughly 11 TB for one copy: 367 GB per day multiplied by 30. A local sample may show a different total if its bitrate differs or varies. The final purchase must also account for filesystem overhead, safety margin, backup copies and any redundancy that reduces usable capacity. Treat the calculation as a planning baseline to test, not a measured result.
If you prefer not to keep a local machine running to send the channel, StreamNeo can remove that specific operating burden by turning an uploaded video into a YouTube live stream while your computer is off. That does not decide whether you need local gaming VODs or how much storage to retain; those remain choices about capture, bitrate and archive duration.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How much space does a 24/7 1080p60 gaming recording use?
At YouTube’s recommended H.264 live-ingest rate of 17 Mbps, the arithmetic estimate is about 184 decimal GB per day and 67 decimal TB per 365-day year. That is not a measured file size and excludes filesystem overhead and safety margin. Use your local recording bitrate if it differs from the live stream rate.
Can I use the bitrate shown in YouTube Studio?
Use the bitrate configured for the local recording when estimating files on your own storage. If it records the same encoded stream that you send to YouTube, the live rate can be a useful approximation; separate local settings call for their own input. Check the relevant codec guidance rather than applying the H.264 examples to AV1 or H.265.
Will YouTube keep a complete 24/7 VOD for me?
Do not assume that it will. YouTube’s archive guidance warns that a stream longer than 12 hours may not be captured and recommends a local archive as backup. If a complete history matters, arrange local capture or deliberate sessions and check that the expected recordings exist.
How should I size storage if my recording bitrate varies?
Record a representative session with the intended settings and measure both duration and file size. Scale that measured rate to the retention window, then leave headroom for variation, overhead and any additional copies. A nominal bitrate calculation remains a useful starting point, but it is not a substitute for checking your own files.