Files.com keeps a clean, recoverable copy of your data off your production stack, including the S3, Azure Blob, Google Cloud, and Wasabi buckets your endpoint and server backup tools never touch. The copy is fed over a path with no inbound attack surface, and retention-locked so a compromised credential cannot delete it. You restore to a point in time before the incident, not just whatever your last mirror copied.
Most teams plan for ransomware on desktops and servers and leave their production cloud buckets unprotected. Files.com syncs one bucket into a separate versioned bucket the attacker cannot reach, on the cheap archive tier you already pay for. So the clean copy was never in the blast radius.
Back up one cloud bucket into another: a separate, versioned bucket the production logins can’t reach. Files.com syncs the source in, and restores any point in time back out.
A stolen access key can encrypt, delete, or corrupt a production S3, Azure Blob, Google Cloud, or Wasabi bucket, exactly like it can a file server. The endpoint and VM backup tools that protect your laptops never touch that bucket, so it sits unprotected.
Set up a second bucket with object versioning turned on, then have Files.com sync the source into it on a schedule. Because versioning is on, each run saves a new version instead of overwriting the last. A sync that runs after an attack can’t wipe out the clean copy.
A plain mirror just gives you back whatever the source looked like at the last sync. If the ransomware got there first, the mirror copied the encryption too. Restoring out of the versioned copy lets you go back to a known-good moment from before the attack.
The target is your own bucket, so it can sit on AWS archive or infrequent-access storage. That’s cheaper than the dedicated capacity a backup appliance makes you buy, and you are paying for object storage anyway.
Things the platform already does, set up together to make a copy that lives off your production systems.
When the source is on-prem, the Files.com Agent dials out over one outbound connection to feed the copy. There’s no inbound firewall rule, no VPN, and no open service for an intruder already inside the network to find and use. The network pushes the copy out of itself, so an attacker on the outside has nothing to connect to.
On Enterprise, Support can turn on Archive-Only Mode for the copy. Once a file is written, no one can change, overwrite, rename, or delete it. That holds on any connection method, and not even your own administrators can do it. The mode can’t be turned back off, so it holds up against an attacker who got inside your main systems.
The copy runs as separate, controlled infrastructure with its own logins, nothing mounted from your network, and nothing shared with production. From the on-prem side it is reachable only over the outbound-only Agent, so ransomware that owns your file server still has no path to it.
Every sync run and every access to the copy lands in an audit log no one can edit, kept for 7+ years and exportable to your SIEM. After an attack, that’s the difference between “we think the copy was clean” and a record that shows exactly what it held and who touched it.
“A security-first approach, granular permission model, and detailed audit logging. Easy to enforce least-privilege access across multiple sites.”
“The biggest challenge that Files.com helps us solve is keeping our file transfers secure. We rely most on the ability to keep our data encrypted while it’s stored at rest as well as in transmitting the data.”
Real companies. Real file flows. Real results.
A team thinking about ransomware is usually already running Veeam, Cohesity, or Rubrik, or eyeing a second NAS. Here is where Files.com fits next to each.
Those tools are great at backing up laptops, servers, and virtual machines. Keep them for that. None of them back up your cloud buckets. Files.com fills the gap they leave: the production object storage that ransomware and a stolen login can reach, but that the machine-backup tools never copy.
A second NAS on the same network, mounted with the same logins, is in the blast radius. Ransomware that reaches the file server reaches any NAS it can mount, and a stolen admin login deletes both. The Files.com copy is reachable only over the outbound-only Agent and runs in a write-once mode a stolen login can’t undo. That’s a different kind of protection, not just a cheaper NAS.
Versioning inside the production bucket sits behind the same stolen credentials as the data it protects. The clean copy has to live under logins the production environment never holds. That is the separate bucket Files.com syncs into.
This isn’t the thing that rebuilds the whole datacenter. It’s the spare copy that was never in the blast radius. When ransomware, an insider, or a bad config takes down your main systems, you recover from a copy that lived somewhere the attack couldn’t follow.
The recovery copy is a configuration of Files.com, the platform 4,000+ organizations already run for partner exchange, compliance, and transfer. A scheduled sync, a versioned target, and Archive-Only Mode on the destination: every piece is standard platform capability, with no new appliance to buy and nothing new for your team to babysit.
If Files.com already carries your partner traffic, the recovery copy is a settings project, not a procurement. If it is new to you, the sync and the versioned target stand up during the 7-day free trial, and the point-in-time restore is the first thing to test.
The place a clean copy lives should come with the audit log, identity, and compliance a production system was never built to guarantee.
The copy is held off-site, encrypted with AES-256 at rest and TLS in transit, and every file action goes on the record in the audit log. That’s the control a recovery copy needs, not a backup add-on.
SOC 2 Type II, PCI DSS, and CSA STAR, with a HIPAA BAA and GDPR DPA available. Files.com runs in production at banks, healthcare companies, and other regulated businesses that have to keep a defensible copy of regulated data.
SSO and SAML against Microsoft Entra ID, Okta, Active Directory, Google, OneLogin, and Auth0. SCIM provisioning, nine permission levels, IP allowlisting, and password policies control who can reach the copy at all.
Standing up the out-of-band copy means wiring the sync, the versioned target, and Archive-Only Mode. That’s the kind of thing you want a real engineer on the other end of.
The people who answer the phone are engineers who know the platform, not a tier-one queue reading a script. Archive-Only Mode is enabled by Support, so you reach someone who can stand up the immutable destination with you.
Get the source sync, the versioned target, and the retention-locked destination stood up fast. Strategic enterprise deployments get our onboarding people embedded as forward deployed engineers.
Thorough docs cover sync scheduling, Archive-Only Mode, child sites, and the Agent’s outbound-only connection. That’s enough to plan the recovery posture before you build it.
The backup jobs customers point at Files.com, and what the destination does that the old server did not.
Database dumps, phone-system and firewall backups, and application exports point at one hosted SFTP destination, so every job has an independent copy the night it runs and there is no backup server to patch.
A per-folder rule keeps thirty days, or seven years for the access-control system the institution must retain, and deletes the rest, so the archive never grows without bound and never depends on a script.
A weekly multi-gigabyte backup that a SaaS vendor takes of your data is pulled into your own bucket on a schedule. The copy of your data is no longer only in the hands of the company you would be leaving.
Hundred-gigabyte backup files upload over SFTP without the timeouts a self-hosted box hit, and land on the immutable, cheap tier where a recovery copy belongs.
A workflow-by-workflow parallel run kept frequent carrier exchanges live while Files.com rebuilt transfers, automation, and access for cloud operations.
Read The Story
A PowerShell script and the Files.com CLI now find each timestamped backup automatically, move it offsite, and enforce retention without altering SQL Server.
Read The Story
A cloud-first hybrid design let users bypass the WAN path into Hyderabad while files synchronized to ValueLabs-owned storage and Azure AD governed access.
Read The Story
A timed sync into a versioned, customer-owned bucket now gives IT point-in-time recovery without changing how designers save their work.
Read The Story
What security and IT teams ask most when building a recovery copy on Files.com.
Ransomware-resilient backup keeps a clean, recoverable copy of your data somewhere a compromise cannot follow, and Files.com builds it as an out-of-band copy off your production stack. The copy is fed over a connection with no inbound attack surface, and it is retention-locked so a compromised credential cannot delete or overwrite it. Files.com syncs your source into a separate target you can restore to a point in time before the incident, rather than to whatever the last mirror copied. It is the copy that was never in the blast radius when ransomware, an insider, or a misconfiguration hits the primary.
Files.com backs up an S3 bucket against ransomware by syncing it on a schedule into a second Amazon S3 bucket with object versioning turned on. Because versioning is on, every sync writes a new version instead of overwriting the last. So a sync that fires after an attack does not destroy the clean copy, and you restore out of a known-good version from before the compromise. The target is your own bucket, so it can sit on a cheap archive or infrequent-access tier. The endpoint and VM backup tools most teams run never touch server-side cloud buckets, so this closes that gap.
Files.com does not replace Veeam, Cohesity, or Rubrik, and it is not meant to. Those tools are excellent at backing up laptops, servers, and virtual machines, so keep them for that. Files.com does not do bare-metal restore, application-aware backup, changed-block tracking, or orchestrated failover. What it does is own the gap those tools leave open: the production S3, Azure Blob, Google Cloud, and Wasabi buckets they do not back up. Run Files.com as the resilient secondary copy for your server-side cloud storage, alongside the machine-backup tool you already use.
Immutable file storage on Files.com is Archive-Only Mode, a WORM-style mode that Support enables on Enterprise. Once a file or folder is written, no one can modify, overwrite, rename, or delete it. That includes site administrators, on every connection method. The mode is irreversible by design: once enabled it cannot be turned off for that site. That is exactly the property that makes it resilient to an attacker who lands inside the primary environment. It is a behavioral WORM mode, configured through data retention. Files.com does not hold formal WORM-storage certifications, so if you need certified WORM that is a conversation with our sales team.
An out-of-band copy on Files.com lives off your production stack, reached over a path the production environment dials out to rather than one an attacker can reach into. An on-prem source feeds the copy through the Files.com Agent, which makes a single outbound connection. There is no inbound firewall rule, no VPN, and no listening service for an intruder already inside to discover. The copy is something the environment pushes out of itself. It is not an air gap. The copy is reachable over the network on the Files.com side, but the ingestion path exposes nothing inbound to the compromised network.
A second NAS on the same network, mounted by the same credentials, sits in the blast radius the Files.com copy is built to stay out of. Ransomware that reaches the file server reaches the NAS it can mount, and a compromised admin can delete both. The Files.com copy is reachable from the on-prem side only over the outbound-only Agent, so there is nothing for the intruder to mount or encrypt. On Enterprise it can run in an irreversible WORM mode a compromised credential cannot undo. That is a different security posture, not a cheaper NAS.
Files.com syncs your source into a target bucket where the cloud provider’s object versioning is turned on, so each run preserves a new version rather than overwriting the last. Recovery restores out of that versioned target to a known-good moment before the compromise, instead of returning whatever state the source was in at the last sync. Object versioning is configured in your own S3, Azure, Google Cloud, or Wasabi bucket, so it is your cloud config. Files.com drives the sync into it and the restore back out.
Every sync run and every access to the copy lands in an immutable Files.com audit log, retained for 7+ years and exportable on demand or streamed to your SIEM. After an incident, a 72-hour breach investigation has to answer what the copy contained, when it was written, and who touched it. Files.com answers that from the system of record by default, instead of leaving you to reconstruct it from guesswork.
Files.com backs up on-premise file servers too: drop the Files.com Agent on a server in your datacenter and it bridges a local SMB or NFS share into the platform over an outbound-only connection. A scheduled sync replicates the source to the out-of-band copy on whatever interval your recovery objective needs, with no inbound port opened to the network the Agent runs inside.
The Files.com Agent is available on the Power tier and above, and Archive-Only Mode is an Enterprise capability that Support enables for you. Files.com publishes its pricing publicly, and the storage for the copy can sit on the cheap archive tier you already pay your cloud provider for. Because the full posture is an Enterprise configuration, talking to our sales team is usually the fastest way to scope it. You can also stand up the sync and a versioned target during the 7-day free trial first.
Point the appliance’s scheduled backup at your Files.com site over SFTP with a credential scoped to one folder. The copy lands off the appliance the night it runs, a retention rule ages out old sets, and the folder can sit on Files.com storage or on your own S3, Wasabi or Azure bucket.
Have the vendor deliver to an SFTP account on your Files.com site, or let Files.com pull from the vendor’s SFTP server on a schedule, and sync the file into your own bucket. Either way the copy exists in storage you own, with a record of every delivery and an alert when one is late.
Set a 30-day retention rule on the backup folder in Files.com. Sets older than the window are removed automatically and the deletion is logged, so cleanup stops depending on a cron job on a server that may not survive the incident.
Back up the production cloud buckets your other tools ignore into a separate, versioned, retention-locked copy on Files.com. You restore to a point in time before the incident. Stand up the sync and a versioned target during the 7-day free trial.
No credit card required • Free for 7 days • Live in minutes