Roadrunner SMB™ — Frequently Asked Questions

Last Updated: 2026-06-05

Answers to common questions from AWS® architects, MSPs, and customers about Roadrunner SMB — architecture, performance, billing, security, operations, and support. For step-by-step deployment, start with the Quick Start Guide.

Quick navigation

• Deployment and architecture
• Storage and shares
• Performance
• Security and permissions
• Cluster operation
• Updates and lifecycle
• Billing and licensing
• Support
• Backup and recovery
• Future / not in MVP

Deployment and architecture

What gets installed into my AWS environment?

Roadrunner SMB deploys a CloudFormation® stack into your existing VPC. The stack creates cluster infrastructure: EC2 instances (via Auto Scaling), ECS tasks running the Roadrunner SMB container (Samba, CTDB, winbind, management server), a Network Load Balancer in public subnets (Admin UI on HTTPS/443; SMB on TCP/445 restricted to SmbClientCidr — your VPC/private client networks, not the public internet by default), Amazon EFS® for system configuration, Amazon DynamoDB® for ACL storage and cluster coordination, Secrets Manager (bootstrap secret for First-Time Setup), and CloudWatch Logs.

Roadrunner SMB does not create the EFS filesystems or access points used for customer SMB shares — you create those in your account and select them when creating shares in the Admin UI.

See also: Deployment Guide, Known Limitations — customer EFS

How long does deployment take?

The CloudFormation stack typically reaches CREATE_COMPLETE in about 15 minutes. After that, First-Time Setup (domain join, TLS, first share) usually takes another 10–15 minutes before clients can connect — see the Quick Start Guide timeline.

See also: Quick Start Guide

What AWS services does Roadrunner SMB use?

Core services: EC2, ECS, Auto Scaling, Network Load Balancer, Amazon EFS, Amazon DynamoDB, Secrets Manager, and CloudWatch Logs. The stack also uses VPC networking (private and public subnets, security groups, route tables) and commonly VPC endpoints (S3 and DynamoDB® gateway endpoints are required by default; interface endpoints for ECR, Logs, and Secrets Manager are recommended).

See also: Deployment Guide, VPC Prerequisites

Does Roadrunner SMB store customer file data outside my AWS account?

No. Share file data resides on customer-owned Amazon EFS in your VPC and AWS account. NT ACL metadata and cluster coordination state are stored in DynamoDB in your account. Roadrunner SMB does not move SMB file contents to Roadrunner SMB–operated storage outside your account.

See also: Deployment Guide

Which AWS regions are supported?

Roadrunner SMB is available in AWS regions where the underlying services (EFS, DynamoDB, ECS, NLB, and related dependencies) are available. Deploy from the AWS Marketplace listing in your target region.

See also: AWS Marketplace deployment summary

Can Roadrunner SMB be deployed into my existing VPC?

Yes. Roadrunner SMB is designed to deploy into your existing VPC via Marketplace CloudFormation. Before resources are created, the stack runs read-only VPC discovery and validation. If requirements are not met, the stack fails with a clear error and rolls back.

See also: VPC Prerequisites, Deployment Guide

Does Roadrunner SMB require Active Directory®?

Yes. Active Directory is required for authentication and Windows® ACL enforcement. All SMB access uses domain credentials (Kerberos/NTLM). Guest or anonymous access is not supported. One domain per deployment; cross-domain trust is not supported.

See also: Known Limitations — Active Directory, Quick Start — domain join

Can Roadrunner SMB be used without Active Directory?

No. AD is required. Non–Active Directory modes are not supported. Use Active Directory (AWS Managed Microsoft AD, self-managed AD on EC2, or on-premises AD reachable via VPN/Direct Connect).

See also: Known Limitations

Single-AZ vs Dual-AZ — which should I use?

Dual-AZ (subnets in two Availability Zones) is required for production high availability. Single-AZ is supported for evaluation, development, test, and other non-critical / non-production workloads — it does not provide AZ-level fault tolerance.

See also: Known Limitations — Dual-AZ vs Single-AZ, VPC Prerequisites

Storage and shares

How many shares can I create?

Roadrunner SMB does not publish a hard maximum share count. Each share uses a DynamoDB ACL table in your account; very large share counts should account for AWS service quotas (for example DynamoDB tables per region). For typical departmental and VDI workloads, share count is not a practical constraint.

See also: Admin Guide — Shares

How many users can connect simultaneously?

There is no published per-appliance connection cap. Capacity scales with cluster node count (1–4), instance type, EFS throughput, and NLB distribution across healthy nodes. Size the deployment for your expected concurrent users and metadata/load profile.

See also: Deployment Guide, Performance

What file types are supported?

Roadrunner SMB provides Windows file sharing over SMB3. Standard files and folders on EFS are supported. Protocol features such as named pipes, DFS namespaces, shadow copies (VSS), and quotas are not supported.

See also: Known Limitations

Are there file size limits?

Roadrunner SMB does not document a fixed maximum file size. Practical limits follow Amazon EFS and NFS semantics on the backend. Very large files may exhibit different performance characteristics than a native NTFS® file server.

See also: Known Limitations — EFS/NFS backend

Can multiple shares point to the same EFS filesystem?

Yes. Several SMB shares may reference the same EFS filesystem (typically via different access points). For AWS Marketplace metering, ManagedStorageGBHours counts each unique filesystem once per hour, not once per share.

See also: Known Limitations — billing

Can a share span multiple EFS filesystems?

No. Each share is backed by one EFS filesystem and one access point selected at share creation.

See also: Deployment Guide, Admin Guide — Creating a share

What happens when I delete a share?

By default, deleting a share removes that share’s configuration and does not delete the corresponding share folder or files on EFS nor the share’s ACL table in DynamoDB. During share deletion, a checkbox option is provided for permanently deleting a share, which removes the share configuration and ACL metadata from DynamoDB.

See also: Admin Guide — Deleting a share

Does deleting a share delete my data?

No, not by default. EFS file data is retained after share deletion. If you want the underlying files removed later, delete or lifecycle-manage the data separately in EFS (and remove the EFS filesystem and access-point path contents using your own procedures).

See also: Admin Guide — Deleting a share

Can deleted shares be recovered?

If during share delete you choose to keep the data (default), the share can be recreated later and will attach to a folder by that share name on the EFS filesystem. If you choose to permanently delete the share, all data and ACLs will be removed and are non-recoverable (except from backups, if any).

See also: Admin Guide — Deleting a share

How is storage usage calculated?

AWS infrastructure: EFS accounts for storage usage and reports it in the AWS console (delayed by up to 15 minutes). Roadrunner SMB Marketplace metering: see How are EFS GBs measured for billing? below.

See also: Known Limitations — AWS Marketplace billing

How are EFS GBs measured for billing?

For Marketplace ManagedStorageGBHours, Roadrunner SMB queries Amazon EFS DescribeFileSystems and meters the total filesystem size (SizeInBytes) for each filesystem attached to billable shares — not only data under the share’s access-point path. If you mount an existing EFS filesystem with data already on it, metering reflects the full filesystem size.

See also: Known Limitations — entire filesystem billed

Performance

What determines maximum throughput?

Throughput is primarily bounded by EC2 instance network throughput, Amazon EFS (throughput mode and size), the EC2 instance type (network and CPU), and the NLB → node network path. Roadrunner SMB is network-intensive (SMB front-end, EFS/NFS back-end). Use EFS Elastic throughput (recommended default) and choose high-networking instance types at deploy time.

See also: Known Limitations — performance, Release Notes — performance guidance

How does EFS performance affect Roadrunner SMB?

All file read/write operations go to EFS over NFS; Roadrunner SMB does not cache file data. Latency and throughput follow EFS behavior. Metadata operations can be accelerated by the L1 cache (see below).

See also: Known Limitations — no file data caching

What does the L1 metadata cache do?

The L1 metadata cache (Elastic SMB™ metadata acceleration) speeds directory listings and file attribute lookups by caching metadata in memory on each node. It does not cache file contents — reads and writes always go to EFS.

See also: Release Notes, Known Limitations

Does cache data survive appliance restarts?

L1 metadata cache is in-memory per node and is rebuilt after task or host restart. Durable ACL and cluster state live in DynamoDB and EFS, not in the L1 cache.

How many nodes should I deploy?

See also: Release Notes — cluster sizing, Deployment Guide

When should I scale from 1 node to multiple nodes?

Move to 2+ nodes when you need production high availability, NLB-backed failover across AZs, and rolling updates without a full outage. Stay on 1 node only for lab, evaluation, or other non-critical workloads.

How do I change cluster size after deploy?

Use the Admin UI Cluster page: set Customer Cluster Node Target (1–4) with the slider and click Apply. Alternatively, update Cluster Node Count on the parent CloudFormation stack. Both paths update ClusterSize and trigger asynchronous ASG/ECS convergence.

See also: Admin Guide — Cluster, Deployment Guide — Scaling, Known Limitations — cluster size

How does Roadrunner SMB scale performance?

Add cluster nodes (up to 4) so the NLB distributes SMB connections across more tasks. Tune EFS throughput and instance type for heavier workloads. Metadata-heavy directories benefit from L1 cache and multi-node capacity.

See also: Deployment Guide

What workloads benefit most from multiple nodes?

Concurrent Windows file sharing, VDI, and metadata-heavy directory workloads (many users listing and opening files) benefit from multiple active nodes and NLB load distribution.

How does Roadrunner SMB handle metadata-heavy workloads?

Elastic SMB L1 metadata acceleration and DynamoDB-backed distributed ACL state reduce metadata latency compared to raw NFS-only paths. Multiple nodes increase aggregate connection and metadata handling capacity.

Is Roadrunner SMB suitable for FSLogix® profile storage?

Roadrunner SMB is designed for Windows file shares on EFS, including VDI and FSLogix-style profile workloads (many small files, metadata-heavy access). Validate performance and ACL behavior in your environment before production cutover. FSLogix is a common target workload but is not separately certified. Small-file performance is limited by EFS performance overall for non-cached data.

See also: Release Notes, Known Limitations

Security and permissions

Planning identities and IAM before deploy: Identity and permissions · Deployer permission matrix · AD domain join delegation

How are Windows ACLs stored?

Windows NT ACLs are stored durably in Amazon DynamoDB (per-share tables) and enforced by Samba on each node using Active Directory identities. Permission changes take effect across the cluster without manual per-node sync.

See also: Admin Guide — Share permissions, Deployment Guide

What gets stored in DynamoDB?

DynamoDB holds NT ACL metadata for shares and cluster coordination state (for example CTDB reclock/formation). Each share uses a dedicated ACL table in your account.

See also: Deployment Guide — architecture

How does DynamoDB manage Windows ACLs?

ACL entries are indexed and retrieved by the Roadrunner SMB server when clients access files. Samba applies the ACL model expected by Windows clients while the durable store survives node replacement and cluster events.

Where are ACLs stored?

DynamoDB (durable, regional) for NT ACLs; EFS holds file bytes only. Cluster Samba state is coordinated via CTDB with EFS and DynamoDB backing.

Can ACLs be backed up and restored?

ACL truth is designed to persist across node failure and cluster recovery via the DynamoDB ACL store and cluster bootstrap procedures. For operational backup, include DynamoDB tables and EFS in your AWS Backup or DR plan.

See also: Backup and recovery

How is access authenticated?

All SMB clients authenticate via Active Directory (Kerberos/NTLM). Guest access is not supported. Admin UI access uses HTTPS and supports AD administrators (Domain Admins enabled by default after FTS — disable in Settings for production) or the break-glass Appliance Owner account (rrsmb-admin).

See also: Identity and permissions · Admin Guide — Accessing the Admin UI

How are Active Directory permissions enforced?

Share preset or custom permissions are translated into NT ACLs stored in DynamoDB and enforced on every SMB operation. Domain users and security groups map to Read or Read/Write as configured per share.

See also: Admin Guide — Shares

Can Domain Admins access the appliance?

Yes, when permitted in Settings (Domain Admins access to Admin UI). Enabled by default after First-Time Setup claim; disable in Settings for production and use a dedicated admin AD group instead.

See also: Identity and permissions — Identity 3b · Admin Guide — Settings

What is the Appliance Owner?

During First-Time Setup, a break-glass (non-AD) Appliance Owner account is created (rrsmb-admin, minimum 12-character password) for emergency admin access when AD is not reachable. It provides full Admin UI access but cannot authenticate to SMB shares.

See also: Identity and permissions — Appliance Owner · Admin Guide — Accessing the Admin UI · Quick Start

What administrative actions are audited?

Roadrunner SMB emits immutable audit log events for security-relevant actions (for example login/logout, share create/update/delete, AD join, support mode, and configuration changes). All logs are kept in CloudWatch Logs.

See also: Support & Troubleshooting — Where logs come from · Admin Guide — CloudWatch Logs

Is file data encrypted?

Yes, at rest: Customer file data on EFS uses EFS encryption at rest (AWS-managed). In transit: EFS (NFS) mounts use stunnel (TLS) via amazon-efs-utils between the appliance and EFS.

See also: Known Limitations

Cluster operation

How does cluster management work?

Roadrunner SMB runs 1–4 ECS tasks (nodes) behind an NLB. CTDB coordinates clustered Samba state. Customer-facing routing and failover use the NLB, ECS health checks, and Roadrunner SMB readiness/fencing — not customer-managed floating IPs. Cluster size and stop/start are driven by CloudFormation stack updates — from the Admin UI Cluster page slider or the CloudFormation console — not ad-hoc ECS/ASG edits.

See also: Deployment Guide

How do ASG, Capacity Provider, and ECS work together?

Auto Scaling provides EC2 hosts; the ECS capacity provider places one task per host up to ClusterSize. Stack updates (resize, image update, stop/start) change CloudFormation parameters; ECS and ASG converge asynchronously. Scale-in uses ECS-managed draining so instances with running tasks are not terminated abruptly.

See also: Deployment Guide

How does Samba CTDB fit into the cluster?

CTDB provides clustered Samba state coordination across nodes so multiple smbd instances present consistent share and locking behavior. SMB clients connect to the NLB DNS name; CTDB is not directly configured by customers.

See also: Deployment Guide, AWS Marketplace deployment summary

How are node failures handled?

In multi-node deployments, a failed node is removed from NLB rotation by health checks; surviving nodes continue serving SMB. A replacement node is launched via ASG/ECS. Single-node deployments have no appliance-level HA — failure or update causes service interruption until the node recovers.

See also: Known Limitations, Deployment Guide

What happens if a node crashes?

The NLB stops sending new SMB connections to the unhealthy target. ECS replaces the task on a healthy host. Clients reconnect to the same NLB DNS name; brief disconnects may occur during failover.

How does Roadrunner SMB maintain SMB availability?

ASG manages the EC2 fleet; ECS runs the Roadrunner SMB container cluster as ECS tasks. Multi-node clusters keep at least one healthy node serving while others update or recover. Rolling updates replace one node at a time. NLB health checks on TCP/445 and Admin paths steer traffic only to eligible nodes.

See also: Known Limitations — Software Updates

How is a billing leader selected?

One cluster node acts as the billing leader for Marketplace metering each hour. The leader must be running and, in multi-node mode, hold the formation lease per cluster coordination rules. If the appliance is stopped, no billable usage is recorded for that hour.

Can I scale the appliance to zero nodes?

Yes — for evaluations or periods of inactivity when you want to stop EC2/ECS compute charges. This is not available from the Admin UI Cluster slider (1–4 only).

Recommended: CloudFormation stack update with ApplianceState=Stopped on the parent stack — scales ECS and ASG to zero while retaining EFS and DynamoDB.

Manual (AWS Console): set the appliance ASG desired capacity to 0, then terminate any remaining EC2 instances.

To restart: update the CloudFormation stack with ApplianceState=Running and your Cluster Node Count, or set ASG desired capacity back to ClusterSize (align ApplianceState on the stack if you stopped manually). Marketplace software metering stops while compute is at zero; retained AWS resources (EFS, NLB, DynamoDB, etc.) may still incur charges.

See also: Deployment Guide — Stop and start

What happens when the appliance is restarted?

On start, ASG and ECS scale back to ClusterSize, tasks bootstrap, CTDB rejoins, and SMB service opens when healthy. EFS data and DynamoDB ACL state persist across stop/start. Brief SMB unavailability occurs during startup.

See also: Deployment Guide — Stop and start

Updates and lifecycle

How are software updates applied?

Roadrunner SMB supports automatic rolling updates. New container releases are discovered from the Marketplace release ECR repository against the seller-published approved release manifest (stable channel). When a newer approved build is detected and automatic updates are enabled, the appliance schedules a CloudFormation update for the next local midnight after detection (Region-local timezone of the deployed AWS Region). ECS performs rolling task replacement; EC2 host changes use ASG rolling replacement when the launch template or AMI changes.

Use Apply latest approved version on the Admin UI Software Update page to adopt a detected release immediately. Use Defer to postpone a scheduled update by 24 hours.

See also: Known Limitations — Software Updates, Admin Guide — Software Updates

Is Roadrunner SMB blue-green deployment?

No. Roadrunner SMB is a managed appliance. Software updates are automatically delivered and applied using controlled rolling-update procedures (ECS for containers, ASG for hosts) — not a customer-operated blue/green cutover.

See also: Known Limitations — Software Updates

How do rolling updates work?

With two or more nodes, replacements are sequential so at least one node continues serving SMB while others update. Single-node deployments experience a brief interruption during update. Container updates change only the application image; host updates replace the Amazon Linux 2023 instance.

See also: Release Notes — Software updates

Will users be disconnected during updates?

Multi-node: brief SMB reconnects may occur as individual nodes drain and return. Single-node: expect a short full outage during replacement. Clients should use the stable NLB DNS name so they reconnect automatically.

Can automatic updates be disabled?

Yes. Set AutoUpdateEnabled=false in CloudFormation at deploy time, or toggle Automatic updates off on the Admin UI Software Update page. Disabling is possible but not recommended for production — security and stability fixes ship as updates.

See also: Admin Guide — Disabling auto-update

How can I determine which version is running?

The Admin UI sidebar shows version and build; the latest available version is also shown on the Software Update page.

See also: Admin Guide — Version Information

What is Appliance Reset?

Reset Appliance (on the Setup page) clears First-Time Setup and AD join state so the wizard can run again. Use it when you need to change Active Directory domain membership or repeat product setup without redeploying the stack. Reset re-runs First-Time Setup for product configuration while retaining customer shares, EFS data, and ACLs in DynamoDB. Authorize the wizard with the recovery secret from Secrets Manager — not initialSetupToken (see Quick Start — bootstrap credentials).

See also: Known Limitations — Leave Domain, Support & Troubleshooting

Does Appliance Reset delete data?

No. Reset does not remove customer file data on EFS or ACL metadata in DynamoDB, and share definitions are retained. It resets appliance control-plane and AD join state so you can complete First-Time Setup again — for example to join a different domain.

Billing and licensing

Is there a free trial?

RRSMB is billed hourly through AWS Marketplace rather than requiring a long-term commitment. A formal Marketplace free trial may not be available for this listing, but hourly metered billing lets you run only the shares and storage you need — delete shares or the CloudFormation stack when finished to stop RRSMB software charges.

See also: What am I charged for?, How do I stop software charges?

What am I charged for?

RRSMB software charges are based on two hourly Marketplace dimensions:

• ShareHours: $0.10 per Windows SMB share connected to EFS, per hour
• ManagedStorageGBHours: $0.00007 per mounted EFS GB-hour

AWS infrastructure charges — EC2, EFS, load balancing, NAT, CloudWatch, DynamoDB, data transfer, and related services — are billed separately by AWS.

See also: How does AWS Marketplace billing work?, Known Limitations — billing

Are charges per node?

No. RRSMB software charges are not per node. Node count affects your AWS infrastructure costs (such as EC2 and load balancing), but RRSMB Marketplace software charges are based on Windows SMB shares connected to EFS and mounted EFS storage only.

See also: What billing dimensions does Roadrunner SMB report?

How do I stop software charges?

Delete shares from the Admin UI, or delete the RRSMB CloudFormation stack. RRSMB software billing is hourly, so ShareHours stop accruing for a removed share on the next hourly metering cycle.

See also: Am I billed while the appliance is scaled to zero?

Do I need Windows Server®?

No Windows Server is required for the RRSMB appliance layer. Windows clients access shares using SMB3, and RRSMB integrates with Active Directory for authentication and Windows-style ACLs.

See also: Does Roadrunner SMB require Active Directory?

Is this a container product?

RRSMB is delivered through AWS Marketplace and deployed with CloudFormation into your VPC. Internally it uses containerized services on AWS infrastructure, but buyers interact with it as an SMB appliance — subscribe, launch the template, and manage shares from the Admin UI.

See also: What gets installed into my AWS environment?

How does AWS Marketplace billing work?

Roadrunner SMB is subscribed via AWS Marketplace. Usage is reported on two dimensions: ShareHours (enabled billable shares per hour) and ManagedStorageGBHours (EFS storage attached to billable shares, in GB-hours). Charges appear on your AWS bill under Marketplace; final pricing may reflect private offers, credits, and taxes calculated by AWS.

See also: Known Limitations — billing, Admin Guide — Billing & Licensing

What billing dimensions does Roadrunner SMB report?

Shares marked billing-excluded are omitted. Each EFS filesystem is counted once per hour even if multiple shares mount it.

See also: Known Limitations

How are ShareHours calculated?

Each materialized, EFS-backed share that is not billing-excluded and whose appliance is running counts as one ShareHour for that clock hour.

How are ManagedStorageGBHours calculated?

Roadrunner SMB calls EFS DescribeFileSystems for each unique filesystem ID attached to billable shares, converts reported size to whole binary GiB, and sums across filesystems for the hour.

What happens when the appliance is offline?

When the appliance is stopped or tasks are not running, shares are not billable for ShareHours and storage metering for that hour. Ledger rows may show offline status for hours without a running billing leader.

Am I billed while the appliance is scaled to zero?

No Roadrunner SMB ShareHours or ManagedStorageGBHours for hours when the appliance is stopped (ApplianceState=Stopped). You still pay underlying AWS infrastructure you keep (for example EFS storage, DynamoDB, NAT) per AWS pricing.

See also: Deployment Guide — Stop and start

Can I view my billing history?

Yes, in the Admin UI Billing & Licensing page: license status, last completed hour, per-share and per-EFS breakdown, and metering history (ledger rows). The UI shows quantities, not estimated dollar amounts.

See also: Admin Guide

Why does AWS Billing differ from Roadrunner SMB usage in the Admin UI?

Roadrunner SMB reports Marketplace usage only (ShareHours and ManagedStorageGBHours). Your AWS bill also includes separate charges for infrastructure Roadrunner SMB runs on and storage you own, for example:

• Amazon EFS (storage, throughput, backups)
• EC2 (cluster hosts)
• ECS (orchestration — typically minor line item)
• Network Load Balancer (hours and LCU)
• DynamoDB (ACL and coordination tables)
• NAT Gateway, VPC endpoints, and data transfer

It is normal for total AWS spend to be higher than Marketplace line items alone. Private offers and credits also affect the Marketplace portion.

See also: Known Limitations — billing

Does Roadrunner SMB include AWS infrastructure costs?

No. The Marketplace subscription covers Roadrunner SMB software usage metering. All underlying AWS service charges are billed by AWS separately in your account.

Support

What information does the Support Report contain?

The Support Report (.zip) includes software version and build, cluster state and node roster, configuration snapshot, last 72 hours of CloudWatch logs, and diagnostic data for common triage scenarios.

See also: Support & Troubleshooting

Does the Support Report contain sensitive information?

It can. The Admin UI offers redaction levels (Safe, Extended, Unredacted). Safe redacts sensitive fields by default. Review the bundle before sending if your policy requires minimal disclosure.

See also: Support & Troubleshooting

Can the Support Report be safely shared?

Use the Safe redaction preset for first-line support unless support requests more detail. Reports are downloaded locally — they are not uploaded automatically to Roadrunner SMB.

How do I contact support?

Use the Email Support link on the Roadrunner SMB homepage. Attach a Support Report for fastest triage. Initial response is best effort within one business day.

See also: Support & Troubleshooting

How do I collect diagnostic information?

Generate a Support Report from Admin UI → Support and email it to Support.

See also: Support & Troubleshooting

How do I determine whether billing is healthy?

Open Billing & Licensing. Check Billing health, last completed hour status (Billed, Pending, Failed, Offline), and metering history chips. In Marketplace live metering, the hourly leader tick is authoritative.

See also: Admin Guide

How do I determine whether the cluster is healthy?

Check the Dashboard (cluster status, node count, SMB service), Cluster page (per-node health), and NLB target group health in the EC2 console. All nodes should be green and NLB targets healthy before declaring production-ready.

See also: Support & Troubleshooting, Admin Guide — Dashboard

What should I include in a support request?

1. Environment (stack name, region, cluster size)
2. Support Report (Safe redaction unless asked otherwise)
3. Symptom, time window, and steps to reproduce
4. Whether a recent update, resize, or stop/start occurred

See also: Support & Troubleshooting

Backup and recovery

Where is my data stored?

File bytes: customer-selected Amazon EFS file systems in your VPC. ACLs and cluster metadata: DynamoDB in your region. Configuration: CloudFormation stack, Secrets Manager, and EFS cluster paths provisioned by the stack.

See also: Deployment Guide

How should I back up my data?

Use AWS Backup, EFS-to-EFS replication, or your standard file-backup tools against the EFS filesystems that hold share data. Back up DynamoDB ACL tables as part of cluster metadata DR. Roadrunner SMB is not backup software.

How do I restore data?

Restore EFS from AWS Backup or your backup product. After restore, reattach filesystems via share configuration if needed. Restore DynamoDB tables if ACL metadata recovery is required. Redeploy or restart the stack if the appliance itself was lost.

Does Roadrunner SMB provide backup software?

No. Use AWS and third-party backup solutions for EFS and DynamoDB. Roadrunner SMB exposes SMB access to EFS only.

What happens if an EFS filesystem is deleted?

SMB shares pointing at that filesystem will fail. Roadrunner SMB cannot recover deleted EFS data. Prevent accidental deletion with IAM policies, backup policies, and deletion protection on critical filesystems.

Can Roadrunner SMB be recovered after accidental stack deletion?

Yes. EFS filesystem share folders and DynamoDB tables remain intact upon stack deletion to protect your data (they must be deleted manually if you want them removed). Redeploy from AWS Marketplace CloudFormation. EFS and DynamoDB data survive if those resources were not deleted with the stack (customer share EFS is separate). You must reconfigure shares, domain join, and Admin settings.

How are share definitions backed up?

Share definitions live in the appliance control plane (persisted on cluster storage). Include stack configuration export, Admin configuration, and operational runbooks in DR docs.

How are ACLs backed up?

ACLs are stored in DynamoDB. Use AWS Backup for DynamoDB or point-in-time recovery (if enabled) as part of your DR strategy.

What should I include in disaster recovery planning?

• EFS file data (backups, replication)
• DynamoDB ACL tables
• CloudFormation stack template and parameters (especially BackendImageUri, networking)
• Active Directory availability and domain join credentials
• NLB DNS name clients use (NlbDnsName) and any customer DNS CNAMEs
• Secrets Manager bootstrap/recovery secrets (operational access)

Cross-region DR is not supported — plan single-region recovery.

See also: Known Limitations — no cross-region DR

Future / not in MVP

The following are not supported or documented for Roadrunner SMB today. See Known Limitations for current boundaries.

• Cross-region disaster recovery and multi-region deployments
• Non–Active Directory authentication modes
• MSP multi-tenant control plane (one stack per customer VPC deployment today)
• Licensing outside AWS Marketplace
• Hybrid cloud (on-premises SMB gateway)
• DFS namespaces, shadow copies, SMB Multichannel, and related enterprise NAS features

Related documentation

• Quick Start Guide
• Identity and permissions
• Deployment Guide
• Admin Guide
• Known Limitations
• Support & Troubleshooting
• Release Notes