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 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, read-only, 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. So 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.
A second NAS on the same network, mounted with the same logins, is in the blast radius. Ransomware that reaches the file server reaches it too. From the on-prem side, the Files.com copy is reachable only over the outbound-only Agent, and it runs as separate, controlled infrastructure, not part of your production setup.
Every sync run and every access to the copy lands in an audit log no one can edit, kept for 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.
The big backup tools grew up protecting machines, not cloud storage. So the data sitting in production S3, Azure, Google Cloud, and Wasabi buckets is mostly unprotected against ransomware and a stolen login. Files.com runs a Veeam-like process from one of those buckets into a separate, versioned, read-only bucket the attacker can’t reach.
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.
Files.com backs up the cloud buckets that machine-backup tools never touch: S3, Azure Blob, Google Cloud, and Wasabi. Veeam, Cohesity, and Rubrik protect laptops, servers, and virtual machines, so keep them for that. The production storage that ransomware and a stolen access key can reach is the copy they leave unmade. That’s the copy Files.com makes.
Run Files.com as the spare copy for that storage: a separate, controlled, can’t-be-edited copy with nothing for an attacker to connect to, built from a platform your team may already run for partner exchange, compliance, or transfer. It’s the copy that survives the attack, restored to a point in time from before it happened, on the cheap archive tier you already pay for.
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, with an audit log of every file action that no one can edit, kept for years, and AES-256 at rest with TLS in transit. 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. Used in production by banks, healthcare, and other regulated industries that have to keep a defensible copy of regulated data.
SSO and SAML against Microsoft Entra ID, Okta, Active Directory, Google, OneLogin, and Auth0, with SCIM provisioning, nine permission levels, IP allowlisting, and password policies on 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, on the cheap archive tier you already pay for. Stand up the sync and a versioned target during the free trial.
No credit card required • Free for 7 days • Live in minutes