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.
What security and IT teams ask most when building a recovery copy on Files.com.
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