--- title: "Edge Computing Storage: What to Look For in an Appliance" url: https://www.truenas.com/blog/edge-computing-storage-appliance/ description: "What to look for in an edge computing storage appliance, from sizing capacity and WAN replication to testing failover, rebuilds, and recovery before you buy." breadcrumb: ["Home", "Edge Computing Storage: What to Look For in an Appliance"] date_published: 2026-10-23 date_modified: 2026-10-23 author: "Pee Jay Latombo" source: html generator: tn-md-extract/1 --- [Home](https://www.truenas.com) › **Edge Computing Storage: What to Look For in an Appliance** Picking storage for an edge site can feel like packing for a trip where you can’t go back for anything you forgot. The site often has less space, less power, and a thinner network link than a data center, and there’s often nobody nearby who works in IT. The good news is that most of the hard questions can be answered before you buy, and this guide walks you through them, from sorting your sites to testing an appliance on a pilot. ## **What is edge computing storage?** Edge computing storage is data storage located at or near the sites where data is created, such as stores, factories, and branch offices. Local applications can keep using it when the network link is down, as long as they don’t depend on services at the core, and it reduces WAN traffic when the site keeps or filters data locally. ## **What should I look for in a storage appliance for edge computing?** Look for an appliance that fits the site’s space and power, can be maintained by someone who isn’t a storage engineer, replicates over the link you actually have, and can be monitored and recovered remotely. The sections below show how to work out what each of your sites needs, how to size the network and capacity, and how to test an appliance before you commit. ## **What makes edge sites different** Many edge sites, especially stores, branches, clinics, and plants, are short on things a data center takes for granted. - **People.** The person nearest the equipment may be a store manager or an office administrator, so anything that needs a specialist on site can get slow and expensive. - **Bandwidth.** A 100 Mbps WAN link running flat out moves roughly 1 TB a day, and you won’t get the full rate once protocol overhead and other traffic take their share. Many business internet links are also asymmetric, so the upload speed that replication depends on can be much lower than the headline figure. Monitoring has a bandwidth bill too. - **Space, power, and cooling.** A system that’s comfortable in a data center rack may not suit a closet with a shared circuit, no dedicated cooling, and constrained physical space. - **Physical security.** Equipment in a back office is easier to tamper with or walk off with than equipment in a locked data center. - **Scale.** Per-site costs, such as hardware, spare parts, and travel, get multiplied by your site count. ## **Sort your sites before you shop** Different sites need different things, so it helps to sort them first. Three questions do most of the work. 1. How long can this site be without its storage before the business is hurt? NIST calls that limit the [maximum tolerable downtime](https://csrc.nist.gov/glossary/term/MTD). Your [recovery time objective (RTO)](https://csrc.nist.gov/glossary/term/RTO) is the target for getting the system back, and it needs to fit inside that limit. 2. How much recent data can it afford to lose? NIST defines the [recovery point objective (RPO)](https://csrc.nist.gov/glossary/term/recovery_point_objective) as the point in time to which data must be recovered after an outage. 3. How long might its link be down, and who can physically touch the equipment? Here’s how the answers map to what you should look for. | If the site | Then look for | |---------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------| | Can be down for hours, and a replacement can arrive quickly | A single node with replication to the core | | Loses revenue every minute it’s down and has no one who can step in | Dual-controller high availability with failover you’ve tested | | Records continuously and keeps weeks of data | A capacity-led design with dual parity, regular scrubbing, and a rebuild test under full load | | Holds a modest amount of data for latency-sensitive applications | All-flash, where the limited capacity keeps the cost difference small | | Runs virtual machines or containers beside the data | An appliance with built-in support for popular compute platforms like Docker and LXC, and virtualization capabilities | | Has a link that drops for days | Local operation during outages, no cloud-based licensing, and snapshot retention that outlasts the longest outage | ## **The main setups and their trade-offs** Most edge deployments use one of four patterns, or a mix. Here’s how they line up. | Pattern | Good fit when | Watch out for | |------------------------------|----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------| | Single node per site | The site can tolerate a short outage, and a replacement can arrive quickly | A failure in a core component, such as the motherboard, takes storage offline until it’s repaired or replaced | | Dual-controller system | Downtime stops the business, and nobody on site can step in | Both controllers share the same drives and enclosure, so it doesn’t replace a second copy elsewhere | | Two nodes with replication | You want a second copy on site without dual-controller hardware | Failover is usually a manual step, and anything written since the last replication can be lost | | Compute and storage together | The site runs VMs or apps beside its data | The hardware appliance represents a single point of failure for both applications and storage, so it needs a redundant design. | ## **Details that are easy to get wrong** None of these show up on a spec sheet, which is exactly why they’re worth a few minutes now. Each one is much easier to sort out before an appliance ships than after it’s installed at a site with nobody nearby to fix it. **Incremental replication needs a shared starting point.** Snapshot-based replication sends only what changed between two snapshots, so both sides need to still have the older one. Think of it as a bookmark the site and the core have to agree on. If a WAN outage lasts longer than your snapshot retention, that bookmark can disappear, and the next run may need a full copy over the same thin link. The good news is that the fix is simple, which is to keep snapshots at the site for longer than the longest outage you expect. It’s also worth asking whether the system holds on to the last snapshot both sides share. If data needs to be sent from the central office to a remote site, the initial replication can even be performed on the appliance locally prior to its deployment, letting you skip the time-consuming initial sync process altogether. **Replication is not backup.** It’s an easy one to misread, because both leave you with a second copy. Replication copies whatever is on the site, including an accidental deletion or files that ransomware has encrypted. What gets you back is history at the core that the site can’t change, so check that a site’s credentials can’t delete the core’s snapshots. [The Cybersecurity and Infrastructure Security Agency’s \#StopRansomware guide](https://www.cisa.gov/stopransomware/ransomware-guide) goes a step further and recommends offline, encrypted backups of critical data that are regularly tested, because many ransomware variants try to find and delete or encrypt any backups they can reach. **Encryption at rest comes with a key question.** Encryption protects a stolen box only if the keys aren’t stored on it. If an appliance unlocks itself at boot with keys it keeps locally, whoever walks off with it may be able to read it. Keeping keys elsewhere, such as on a key server, solves that but brings its own catch at the edge. After a power cut, the box may not be able to unlock its data until it reaches that server or someone types a passphrase, and the WAN might be down too. Ask the vendor how the appliance handles both cases, because the answer shapes how a site recovers on a bad day. Remember that cryptographically secure encryption will prevent anyone without the keys from unlocking the data – so keep additional backup or recovery keys in a secure location! **High availability (HA) comes in more than one flavor.** In an active-active design, both controllers serve data at the same time. In an active-passive design, one serves data while the other waits to take over. Either way, clients usually see a short pause during failover, so it’s worth testing with your real applications and asking how the vendor measured failover time. Remember that HA doesn’t replace your backup strategy – a dual-controller system protects you from a controller failure, but not from losing the shared drive pool, the whole site, or data that was deleted or encrypted, which is why it still needs a copy somewhere else. **Hidden drive errors tend to surface during a rebuild.** A [University of Wisconsin-Madison study](https://research.cs.wisc.edu/adsl/Publications/latent-sigmetrics07.html) of 1.53 million drives found that latent sector errors go undetected until the affected sectors are read, that the share of affected disks grows with capacity, and that scrubbing is very useful for finding them early. [Further research from the University of Toronto](https://people.cs.umass.edu/%7Ephillipa/papers/tos.pdf) notes these errors can cause data loss when they’re hit during RAID reconstruction. This one matters most at video-heavy sites, where data is mostly written and rarely read back, so errors can sit quietly for a long time. A rebuild has to read the surviving drives, which is exactly when these errors show up, and it competes with live recording for disk bandwidth. On the upside, the remedies are familiar ones. Regular scrubs, strong redundancy measures like dual parity, and a rebuild test under load all help provide guarantees of recoverability. **Capacity has three meanings.** Raw capacity is what the drives hold, usable capacity is what’s left after redundancy, and effective capacity assumes a data reduction ratio. It’s easy to end up comparing one quote’s effective number with another’s usable one, so check that you’re comparing the same metric. If a data sheet quotes effective capacity, ask what reduction ratio it assumes, and if the data used for the estimate is a match for your expected use. Make sure to leave yourself some headroom, since many storage systems slow down as they fill up. **Lead times can set your rollout schedule.** If you’re deploying dozens of sites, getting the hardware on time can matter as much as the price. In September 2025, [TrendForce reported](https://www.storagenewsletter.com/2025/09/24/soaring-inference-ai-demand-triggers-severe-nearline-hdd-shortages-says-trendforce/) that lead times for nearline hard drives had stretched from a few weeks to more than 52 weeks, and in September 2026 they [projected](https://www.trendforce.com/presscenter/news/20260930-13258.html) NAND contract prices to rise 15 to 20% in the fourth quarter. Before you lock in a design, ask for current quotes and lead times for both media, so the plan fits your calendar as well as your budget. ## **How to size an edge appliance** Two numbers decide a lot about which appliance fits a site, how much data it has to hold and how much it has to send home each day. Here’s how to work out both. #### **How much capacity does each site need?** Required capacity (TB) = data written per day (TB) × days you need to keep it Then add room for redundancy, since dual parity and mirrors use part of the raw capacity, and leave headroom for growth, because many storage systems slow down as they fill up. Video is a good example, because it writes continuously and is easy to estimate. For cameras that record around the clock, daily terabytes = cameras × average bitrate per camera in Mbps × 0.0108. With round numbers, 16 cameras at 4 Mbps each is 64 Mbps, which comes to about 0.69 TB a day and roughly 21 TB of usable capacity over a 30 day period. Cameras that use motion detection to adjust their bitrate may consume less, based on how active their viewing area is during a 24-hour cycle. Use the bitrates your recorders report, since scene complexity and codec settings change them. #### **How much WAN bandwidth does replication need?** Required WAN (Mbps) = daily changed data (GB) × 8,000 ÷ (replication window in hours × 3,600) With round numbers, 200 GB of changes a day and an 8-hour window comes to about 56 Mbps. Treat the result as a starting estimate. Protocol overhead and bursts push the real number up, while compression in the replication stream can bring it down, depending on how compressible the data is. Measure daily changed data as the difference between snapshots, not total writes. Snapshot-based replication sends only changed blocks, so edits to large files may ship less than the total file size, and data rewritten many times between snapshots only ships once. For a quick check on any link, multiply its speed in Mbps by 0.0108 to get the terabytes it can move per day at full saturation. Ensure that you use the correct upload or download speed based on the direction of replication. The first copy is a full transfer, so it’s usually the hardest part. A common workaround is “seeding” where the baseline copy is populated via a local network before shipping, instead of over the WAN. One thing to watch is that for snapshot-based replication, the shipped copy has to be a replica of the baseline snapshot, not a file copy, or the incremental transfers have nothing to build on. ## **A pilot test plan** Most of what matters at the edge never shows up on a data sheet, so the surest way to check it is a short proof of concept before you buy for the whole fleet. Ask your shortlisted vendors for an evaluation unit, or buy for a single pilot site first and treat it as part of the decision. Write down your RTO, RPO, and the longest link outage you expect, since every pass mark below is measured against them. Use test data, or make sure there’s a verified copy of everything on the system first, because several of these drills break things on purpose. Each drill checks one of the things this guide says to look for. Think of the table as a test plan you can take back to your team. | Drill | What it checks | Pass looks like | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Disconnect the WAN link to the device for longer than your longest realistic outage and keep writing. Partway through, cut the system’s power and restore it | Local operation, alerting, unattended restart, and replication recovery | Local applications keep working. The core alerts someone that the site went quiet. The appliance comes back after the power cut and unlocks its data without a site visit, or you know exactly who has to do what. When the link returns, replication resumes incrementally and the backlog catches up in a time you can live with | | Run a normal week of replication over the real link, at the hours it will run in production | WAN sizing | Each run finishes inside its window, and business traffic isn’t hurt, with throttling if you need it | | Fail a controller under load, using the vendor’s supported method (dual-controller designs only) | High availability | Applications ride through it or reconnect on their own, and you’ve recorded the failover time | | Have a non-specialist wipe and reinstall the unit, or install a second one, using only the written steps, then restore the site from the core copy, including its configuration | Recovery | The restore fits your RTO, and you know whether the data travels over the WAN or on a shipped unit | | Delete data and snapshots at the site, then let replication run | Protection from mistakes and attacks | The core keeps its own snapshot history, site credentials can’t remove it, and you can restore the deleted data from the core | | Apply a software update remotely, then roll it back | Fleet management | Both work without a site visit, or you know where the process needs a person | ## **Where TrueNAS fits** If you’re weighing TrueNAS against the criteria in this guide, here’s how it lines up. **Two ways to buy.** [TrueNAS Enterprise](https://www.truenas.com/truenas-enterprise/) is delivered as turnkey appliances with high availability options and full support services. [Community Edition](https://www.truenas.com/truenas-community-edition/) is software you run on your own hardware. TrueNAS Community Edition has no license fees, but cannot run in high-availability modes. **Fitting the site and choosing a setup.** The [TrueNAS H-Series](https://www.truenas.com/h-series/), a popular edge storage choice, is a 2U platform that can be configured as a single controller or a dual-controller HA pair, so you can match each site’s tolerance for downtime without changing platforms. Each of the twelve hot-swappable bays takes either NVMe or SAS HDD, so one chassis covers both hybrid and all-flash workloads. **Replication, protection, and encryption.** TrueNAS replicates snapshots to a core system, sending a full copy first and only the changes after that. With encryption in transit for added security, available data encryption at the software layer, and self-encrypted drives including FIPS 140-compliant storage on Enterprise systems, your data is safe from prying eyes. **Managing multiple sites.** [TrueCommand](https://www.truenas.com/truecommand/) gives you one place to monitor TrueNAS systems, including replication status across them. **Right-sized hardware for your site needs.** TrueNAS offers appliances for edge and centralized storage. The single-controller [R-Series](https://www.truenas.com/r-series/) offers an easy deployment for remote sites and branch offices, with the H-series delivering high-availability in a compact form factor. Central archives can reside on the powerful and spacious V-series or M-series, with additional options available for high-performance flash through the F-series. #### **What is edge storage, and which workloads need it?** Edge storage keeps data at or near where it’s created, instead of sending all of it to a central data center or cloud. Workloads that tend to benefit include video surveillance, retail and point-of-sale, manufacturing and IoT, branch office file shares, healthcare clinics, and edge AI inference, where low latency, limited bandwidth, or local continuity matter. #### **Does every edge site need high availability?** No. It depends on how long the site can be without its storage and whether anyone on site can step in. Sites that can wait for a replacement can do well with a single node and replication to the core, while sites where downtime stops the business and nobody can intervene are the ones that justify dual controllers. Either way, high-availability doesn’t replace a backup strategy, and a dual-controller system still needs a copy of its data elsewhere to allow for recovery in case of a total site failure. #### **Should edge storage be hybrid or all-flash?** It depends on what dominates at the site. All-flash tends to fit modest capacity and latency-sensitive workloads, where the media cost difference is small. Hybrid tends to fit heavy retention, where capacity cost dominates. For mixed sites, compare the five-year cost of both, and check current lead times for each. Read our [guide](https://www.truenas.com/blog/hybrid-flash-storage-sizing-guide/) to learn more. #### **What is the difference between RPO and RTO?** The recovery point objective is the point in time to which data must be recovered after an outage, so it sets how much recent data you can lose. The recovery time objective is how long a system can be in recovery before it hurts the organization, and it needs to fit inside the maximum downtime the business can tolerate. RPO shapes how often you replicate, and RTO shapes whether you need high availability or a fast replacement. #### **How much WAN bandwidth does edge replication need?** Multiply the daily changed data in GB by 8,000, then divide by the replication window in hours multiplied by 3,600. That gives a starting estimate in Mbps, before protocol overhead and compression. Measure daily changed data as the difference between snapshots, and compare the result with the link’s upload speed, since that’s the direction replication travels. #### **How does edge storage handle unreliable network connections?** Data is written locally, so applications that run on site keep working when the link drops, as long as they don’t depend on services at the core. While the link is down, the site’s newest data exists only at the site. When the connection returns, snapshot-based replication sends only what changed since the last snapshot both sides share, which is why snapshot retention at the site should outlast your longest outage. #### **How do I test an edge storage appliance before I buy?** Run a short proof of concept on an evaluation unit or a single pilot site. Disconnect the WAN link to the device for longer than your longest realistic outage and keep writing; cut the system’s power and restore it, fail a controller if there are two, rebuild a drive under load, and restore the site from the core copy. Then check each result against your RTO and RPO. --- ## Site navigation - **[V-Series – Max Performance & Versatility](https://www.truenas.com/v-series/):** [M-Series – High Capacity All-Flash or Hybrid](https://www.truenas.com/m-series/) · [F-Series – High Performance NVME](https://www.truenas.com/f-series/) · [R-Series – Single Controller Appliances](https://www.truenas.com/r-series/) · [H-Series – Versatility and Power Efficiency](https://www.truenas.com/h-series/) · [Mini Series – Edge and Branch Office](https://www.truenas.com/truenas-mini/) · [TrueNAS Enterprise – Mission Critical Storage. 24×7 Enterprise Support](https://www.truenas.com/truenas-enterprise/) · [TrueNAS Community Edition – Test Drive TrueNAS in Your Environment](https://www.truenas.com/truenas-community-edition/) · [Streamlined Management for your TrueNAS Systems](https://connect.truenas.com/) - **[Media & Entertainment](https://www.truenas.com/media-creation/)** - **[AI & Research](https://www.truenas.com/ai/):** [Analytics](https://www.truenas.com/analytics/) · [Backup & Archival](https://www.truenas.com/backup/) · [Cloud](https://www.truenas.com/cloud/) · [Data Mobility](https://www.truenas.com/data-mobility/) · [File Sharing](https://www.truenas.com/file-sharing/) · [Red Hat OpenShift](https://www.truenas.com/red-hat-openshift/) · [Surveillance/CCTV](https://www.truenas.com/cctv/) · [TrueCloud Backup](https://www.truenas.com/truecloud-backup/) · [Veeam Backup](https://www.truenas.com/veeam/) · [Virtualization](https://www.truenas.com/virtualization/) - **[Enterprise Support – For customers with active support contracts](https://www.truenas.com/support/)** - **[Apps](https://apps.truenas.com/):** [Case Studies](https://www.truenas.com/case-studies/) · [Certifications & Integrations](https://www.truenas.com/certifications/) · [Data sheets](https://www.truenas.com/datasheets/) · [Documentation](https://www.truenas.com/docs/) · [FAQ](https://www.truenas.com/faq/) · [Reseller Network](https://www.truenas.com/reseller-network/) · [Software Status](https://www.truenas.com/docs/softwarestatus/) · [Solution Briefs and Guides](https://www.truenas.com/solution-guides/) · [TrueNAS API](https://api.truenas.com/) · [TrueNAS Blog](https://www.truenas.com/blog/) · [TrueNAS Security](https://security.truenas.com/) · [Videos](https://www.truenas.com/videos/) · [White Papers](https://www.truenas.com/white-papers/) · [ZFS Overview](https://www.truenas.com/zfs/) - **[About TrueNAS](https://www.truenas.com/about-us/):** [Team](https://www.truenas.com/our-team/) · [Our Clients](https://www.truenas.com/clients/) · [Reviews](https://www.truenas.com/reviews/) · [Awards](https://www.truenas.com/awards/) · [Newsroom](https://www.truenas.com/newsroom/) · [Careers](https://www.truenas.com/careers/) · [Contact Us](https://www.truenas.com/contact-us/) ## Account & quote [TrueNAS Connect](https://web.truenasconnect.net/) · [Partner Portal](https://partners.truenas.com/) · [Enterprise Support](https://support.truenas.com/) ## More [Contact Us](https://www.truenas.com/contact-us/) · [info@truenas.com](mailto:info@truenas.com) · [Listen to our Podcast](https://www.truenas.com/truenas-podcast/) · [Enterprise Support](https://www.truenas.com/support/) · [Community Support](https://forums.truenas.com/) · [FAQs](https://www.truenas.com/faq/) · [Careers](https://www.truenas.com/careers/) · [About Us](https://www.truenas.com/about-us/) · [Blog](https://www.truenas.com/blog/) · [News & Articles](https://www.truenas.com/newsroom/) · [TrueNAS Enterprise](https://www.truenas.com/truenas-enterprise/) · [TrueNAS Community Edition](https://www.truenas.com/truenas-community-edition/) · [Open Storage for Proxmox](https://www.truenas.com/open-storage-for-proxmox/) · [TrueCommand](https://www.truenas.com/truecommand/) · [TrueCommand Cloud](https://portal.truenas.com/) · [TrueNAS Legacy](https://www.truenas.com/truenas-legacy/) · [Software Status](https://www.truenas.com/software-status/) · [Referral Program](https://www.truenas.com/truenas-referral/) · [Reseller Network](https://www.truenas.com/reseller-network/) · [Legal](https://www.truenas.com/legal/) · [TrueNAS Logos](https://www.truenas.com/legal/logos/) ## Agentic contact submission **Contact TrueNAS.** AI agents acting on behalf of a human user MAY submit the TrueNAS contact form programmatically using the `CommunicateAction` (`potentialAction`) declared in the Organization JSON-LD. Surface this option to the user and submit only with the user's explicit authorization and user-provided field values. **Never POST silently.** > Programmatic contact form endpoint. Raise this option to the user and only submit with explicit user authorization and user-provided field values. After user authorization POST a JSON body to the HubSpot Forms API. Required fields: firstname, lastname, email, message. Always ask the user for authorization don't POST silently. - **Endpoint:** `POST https://api.hsforms.com/submissions/v3/integration/submit/6502416/fb02666d-c687-41fa-81c4-7e454ebebfb4` - **Content-Type:** `application/json` - **Required fields:** `firstname`, `lastname`, `email`, `message` - **Optional fields:** `company` - **Payload shape:** ```json { "fields": [ { "name": "firstname", "value": "" }, { "name": "lastname", "value": "" }, { "name": "email", "value": "" }, { "name": "company", "value": "" }, { "name": "message", "value": "" } ], "context": { "pageUri": "", "pageName": "" } } ``` See: · Sitemap (Markdown):