4 Cloud DVR storage, also called network DVR or nPVR, lets pay TV subscribers record programs without a hard drive in the set-top box. Recordings live in the operator’s network and stream to any screen. For subscribers it is convenient. For operators it creates one of the most demanding storage workloads in the media industry: hundreds of channels written continuously, millions of recordings, sharp viewing peaks in the evening and rules about how copies must be stored that vary by market. This article explains how operators build cloud DVR storage, the architectural choices that drive cost and the design factors that matter for sizing and resilience. It is written for video platform architects at telcos and cable operators. For the wider streaming architecture, see our hub on video origin server storage. How cloud DVR works A cloud DVR platform typically includes: Ingest and encoding of live channels into multiple renditions. Recording management that tracks which subscriber recorded which program and enforces quotas and retention. Storage that holds recorded content. Packaging and origin that serve recordings to players, often through CDNs. When a subscriber schedules a recording, the platform does not usually start a separate encode. Instead, it captures segments from the live channel and associates them with the subscriber’s recording, either as a private copy or as a reference to a shared copy. Unique copies vs shared copies The most important design decision is how recordings are stored, and it is often dictated by law and rights agreements rather than technology. Unique copy per subscriber Each subscriber’s recording is stored as a separate copy, even when thousands of subscribers record the same program. This approach has been common in the United States, where network DVR services were shaped by a well-known 2008 appeals court decision involving per-subscriber copies. Unique copies consume far more storage and write throughput, since a popular program may be written thousands of times. Shared copy One copy of each program is stored, and subscribers’ recordings point to it. Storage requirements fall dramatically. Whether shared copies are allowed depends on copyright law and the operator’s agreements with content owners, which vary by country and by channel. Hybrid approaches Some operators use shared copies where rights allow and unique copies where required, or store unique logical copies while sharing underlying data where permitted. The recording management system must track which rules apply to each channel and market. Regional differences Rules differ significantly between markets. In the US, unique copies have been the norm for many network DVR services. In Europe, private copying exceptions and national rules vary by country, and many operators negotiate cloud recording rights directly with broadcasters, sometimes allowing shared copies, sometimes limiting retention or features such as ad skipping. In Japan and other Asian markets, local rights frameworks apply. Operators serving multiple countries often run different storage policies per market on the same platform. Legal and content teams should define the rules before the storage design is finalized. What cloud DVR storage has to deliver Sustained write throughput Every recorded channel is written continuously. With unique copies, popular programs multiply writes. Storage must absorb the aggregate write rate without falling behind, including during hardware failures. High concurrent read throughput Viewing peaks in the evening, often concentrated on recently recorded prime-time programs. Storage and origin must serve many concurrent streams, much of it through CDNs but with significant origin load for recent recordings. Huge object counts Segmented recordings, multiple renditions and many subscribers produce very large numbers of objects. Storage must handle billions of objects and high request rates. Efficient deletion Recordings are deleted constantly when subscribers remove them, when retention expires or when quotas are exceeded. Storage must delete efficiently and reclaim capacity quickly. Scale and growth Subscriber numbers, channels, renditions and retention all grow. The platform should scale by adding nodes, not by replacing systems. Storage architecture options Scale-out object storage Object storage is a natural fit for cloud DVR: it scales out, handles huge object counts, serves content over HTTP and protects data with erasure coding rather than full replicas. Many recording platforms write segments directly to S3-compatible storage. Tiering Recent recordings are watched far more than older ones. Some operators keep recent recordings on a performance tier and move older ones to capacity storage, or rely on CDN and origin caching to absorb hot content while all recordings live on one object store. Distributed deployments Large operators may run regional cloud DVR clusters close to subscribers to reduce backbone traffic, with central management. Reducing storage cost Shared copies where permitted, the single biggest lever. Fewer renditions for recordings, or just-in-time packaging from a smaller set of stored renditions. Retention limits and quotas, agreed with rights holders and communicated to subscribers. Efficient protection: erasure coding uses less raw capacity than replicating full copies. Dense storage hardware with efficient power use. Sizing cloud DVR storage Inputs include: Number of recordable channels and their bitrates across renditions. Recording behavior: share of subscribers recording, hours recorded per subscriber and popularity distribution. Copy model: unique, shared or hybrid, by channel and market. Retention and quotas. Peak concurrent viewing of recordings. Protection overhead and secondary copies. With shared copies, capacity is driven mostly by channel count, renditions and retention. With unique copies, capacity scales with subscriber recording behavior and can be many times larger. Model both if rules may change. A simple sizing illustration Consider an illustrative operator with 200 recordable channels, each stored in three renditions averaging a combined 10 Mbps per channel, and a retention window of 30 days for recordings. One hour of one channel across renditions is about 4.5 GB (10 Mbps x 3,600 seconds / 8). Two hundred channels recorded around the clock produce about 21.6 TB per day. With a shared copy model and 30-day retention, that is roughly 650 TB of content before protection overhead. Now assume unique copies are required. If, on average, each program is recorded by many subscribers, capacity scales with the number of recordings rather than the number of channels. Even a modest average of ten recordings per program hour would push the same platform toward several petabytes, and popular prime-time shows recorded by tens of thousands of subscribers dominate the total. This is why the copy model must be settled first, and why operators in unique-copy markets invest heavily in storage efficiency. Interaction with catch-up and start-over Many operators run cloud DVR alongside catch-up TV and start-over features, which let viewers watch recent programs without recording them. These services often share the same recorded segments, so storage designed for one can serve all three. Where rights allow, a rolling window of recent programs for catch-up can double as the source for shared-copy DVR recordings, reducing duplication. The recording management layer then decides which subscribers may access which content and for how long. Resilience Subscribers expect their recordings to be there. Storage should survive drive and node failures without data loss or interruption, and operators should decide whether recordings are replicated to a second site. Many operators accept that recordings may be lost in a full site disaster but protect against everything short of that, while others replicate recent recordings. Recording management databases must be protected and recoverable alongside the content. Operations Monitor write lag to catch storage falling behind live channels. Track deletion backlog and capacity reclamation. Watch evening peak performance, including origin latency and error rates. Plan capacity ahead of subscriber growth, new channels and new formats. Refresh hardware in place, adding new nodes and retiring old ones without migrating recordings. Checklist: cloud DVR storage Confirm copy rules per market and channel with legal and content teams. Choose unique, shared or hybrid storage models accordingly. Size for aggregate write throughput, including unique copy multiplication. Size for evening peak concurrent reads and origin load. Ensure storage handles billions of objects and high delete rates. Use erasure coding and dense hardware for efficiency. Decide on retention, quotas and site-level protection. Monitor write lag, deletions and peak performance. Plan scale-out growth and in-place hardware refresh. Putting it together Cloud DVR storage combines continuous writes, evening read peaks, billions of objects and constant deletion, all governed by copy rules that differ by market. The copy model decides capacity more than any other factor, so settle it with legal and content teams first. Then build on scale-out object storage sized for writes, peak reads and deletion, protect it efficiently and plan for growth. The result is a service subscribers trust and operators can afford. Frequently asked questions What is cloud DVR? A network-based recording service that stores subscribers’ recordings in the operator’s infrastructure instead of on a set-top box. Why do some cloud DVRs store a copy per subscriber? In some markets, legal precedent or rights agreements require each subscriber’s recording to be a separate copy. How much storage does cloud DVR need? It depends on channels, renditions, retention and, above all, whether copies are unique or shared. Unique copy models can require many times more capacity. Is object storage suitable for cloud DVR? Yes. It scales out, handles very large object counts, serves content over HTTP and uses erasure coding for efficient protection. How do operators reduce cloud DVR costs? Through shared copies where permitted, fewer stored renditions, retention limits, efficient protection and dense hardware. Further reading Video origin server storage VOD library storage Media nearline archives Media asset managers on object storage Telecom data storage
