Why ransomware-resilient self-hosted file sharing starts with the sync client
The design goal for ransomware-resilient file sharing is recoverability, not prevention alone. A laptop with a sync client can be infected, and once it is, the client will faithfully encrypt the files it can see and push those changes to every other device and to the server. The sync path itself is the threat, so the platform has to keep data that a sync client cannot overwrite or delete. Prevention still matters, but the question for your architecture is what you can restore after an infected endpoint has written to every shared folder it can reach.
This is different from generic file sharing because the usual assumptions break. In a plain share, a user who saves over a file has effectively replaced the only copy. Here, you need file versions and trash bin retention that outlast a burst of encrypted writes, scanning on upload so known malware is not stored as a clean file, and backups that a compromised client cannot reach. Nextcloud and Seafile both sync and share files, and both offer versioning and recovery features, but neither blocks ransomware on its own. Nextcloud has a broader app ecosystem for antivirus and retention, which is relevant if you want those controls inside the same platform. Seafile has a more focused feature set, so you should plan separately for scanning and retention. In both cases, confirm the exact version retention, trash behavior and scanner integration against the current documentation before you commit, and confirm them again in a restore test.
Which requirements shape the design, and where they come from
This table maps each requirement source to what it means for a ransomware-resilient build of self-hosted file sharing. Read each row as a design constraint: the source sets the obligation, and the right column names the build decision it forces. DeployOpen prepares systems and evidence for assessments but does not certify compliance, so confirm final scope with your auditor or counsel.
| Requirement source | What it asks for | What it means for the build |
|---|---|---|
| HIPAA 164.312(b) audit controls | Mechanisms that record and examine activity in systems holding ePHI | Enable and retain Nextcloud audit logging, ship logs off the sync server, and confirm that deletions and restores are recorded so an incident can be reconstructed |
| HIPAA 164.312(e)(1) transmission security | Technical measures guarding ePHI sent over electronic networks | Enforce TLS for sync clients, web and WebDAV, and scanning of inbound files; confirm how external share links are protected in transit and at rest |
| SEC 17a-4(b)(4) preservation | Preserve copies of business communications for not less than three years (broker-dealers) | Keep retention longer than the sync-client deletion window, so a file deleted on a laptop still exists in a preserved copy; confirm with compliance whether files count as records |
| Nextcloud versioning and trash bin | Versions and trashed files kept for a configurable period before purge | Set version and trash retention based on recovery needs and records rules; confirm the retention window is enforced server-side and not controlled by the user's client |
| Nextcloud Retention app | Automatic deletion after a set time, with a notice to users the day before | Use retention deletion only where policy requires it; a deletion rule that runs on a short timer can remove the only recoverable copy of ransomware-encrypted data |
| Backup immutability | Backups that a compromised endpoint or sync account cannot alter or delete | Keep BorgBackup repositories outside the sync data path, with credentials the sync service cannot use to delete archives; confirm append-only or retention locks in your design |
| Antivirus on uploads | Inspection of files entering the platform before users access them | Connect ClamAV or an ICAP scanner to uploads and the background scan; confirm signature update paths, especially in air-gapped or restricted networks |
| Restore evidence | Documented, tested recovery of data to a known good state | Schedule restore tests to a separate environment and keep the results as evidence; a backup that has never been restored is not evidence of recovery |
Which platforms fit ransomware-resilient file sharing and why
Ransomware resilience in file sharing depends on several layers working together: versioning and trash retention, scanning of inbound files, and backups stored outside the sync path. The platforms below differ in how much of that stack ships built in and how much you must assemble and verify yourself.
Nextcloud Server with Antivirus for files
Nextcloud's Antivirus for files app scans uploads as they arrive and runs a background scan of all stored files, deleting infected files and notifying users. It works with ClamAV, Kaspersky Scan Engine or an ICAP-compatible scanner, so you choose the engine. Check that the scanner's signature updates reach it on your network, and test that an EICAR test file is caught and removed from a synced folder before you rely on it.
Nextcloud Retention for deletion control
The Retention app automatically deletes files after a set period and can notify users the day before. It matters for ransomware because it limits how long a clean copy can be removed, but it also deletes data on purpose. Confirm the retention periods against your records obligations and make sure retention rules do not expire the only recovery copy of a shared folder before your backup window covers it.
Nextcloud All-in-One bundled backup and scanning
Nextcloud All-in-One is the official installation method and bundles BorgBackup-based backups and ClamAV antivirus alongside PostgreSQL, Redis and full-text search. This gives a single deployment with the backup and scanning path already wired in. Still verify that Borg repositories are written to storage that a compromised user session cannot reach, and that restores are tested rather than assumed.
Nextcloud support tiers and maintenance
Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers, with Standard including one year of maintenance and Premium adding a lifecycle of five or more years. Support response times are a contract term, so ask which tier covers security fixes for the server and each app you depend on. Pair any tier with a patch cadence, because a supported release still needs upgrades one major version at a time.
Seafile library history and trash
Seafile keeps library history and a trash for deleted items, which gives users a way back from accidental or malicious changes within the retention you configure. Its version history is organized around libraries, so restoring a whole folder after encryption by malware is a different task than restoring one file. Buyers must confirm the retention period, trash behavior and how antivirus is integrated in the exact version they plan to run.
Backup targets outside the sync path
Versioning inside the sync platform does not protect against an administrator account or a sync service that is itself compromised. Design a separate backup target, such as a BorgBackup repository with restricted credentials and append-only or immutable retention, that the file server cannot delete from. Ask any partner to show where backups live, who holds their keys and how a restore is proven.
How the rollout moves from retention settings to a tested restore
This sequence turns retention settings into a restore that has been proven on real data. Each phase ends with a written artifact, so the organization can show what is protected, how it is protected, and that recovery works.
Inventory data and retention needs
Your team and the data owners list the shared folders, groups and external shares, then classify each by business value, regulatory retention and how fast it must be recovered. The delivery partner documents which systems hold copies of this data, including sync clients on laptops. The output is a retention matrix that assigns each class a version window, a trash retention period and a backup target. Confirm the matrix with the data owners before any setting changes, because it defines what a restore must return.
Configure versions and trash retention
Administrators set file versioning and trash bin retention in Nextcloud to match the matrix, and apply retention rules where a class needs automatic deletion schedules. The Nextcloud Retention app can enforce time-based deletion and notify users beforehand, so the team confirms that deletion rules never run ahead of backup coverage. The check is a test account where an overwritten file and a deleted file are both recovered through the web interface and a sync client. The output is a signed configuration record listing each setting and its value.
Deploy antivirus on uploads and background scans
The partner connects an antivirus engine such as ClamAV, Kaspersky Scan Engine or an ICAP-compatible scanner to the Nextcloud Antivirus for files app, so uploads are checked on arrival and the full store is scanned in the background. Scanning limits and signature update paths are set, and infected files are removed with a notice to the user. The team uploads a harmless test signature file to confirm detection, removal and notification. The output is a scan test record and a documented signature update schedule.
Build backups outside the sync path
The partner configures BorgBackup to write deduplicated, encrypted snapshots of the database, data directory and configuration to a repository that the sync server and client devices cannot delete or overwrite. Repository credentials are held by the backup administrators, and retention pruning is set so older snapshots survive a compromised administrator account. Nextcloud All-in-One includes BorgBackup-based backups, which can simplify the initial deployment. The output is a backup job inventory showing source, destination, schedule and retention for each job.
Run restore tests
The team restores a sample of files, a full user folder and a complete instance into an isolated environment, then compares checksums, permissions, versions and database consistency against the source. Each test records the time taken and any gaps found, and failed tests are repeated after the fix. The team also confirms that a restore of an infected file set is not reinfected when the scanner is active. The output is a tested restore log that names the snapshot used, the scope restored and the result for each test.
Write the recovery runbook
The partner writes a runbook with step-by-step procedures for isolating an infected device, disabling affected accounts, choosing the correct snapshot, restoring to a clean environment, reapplying permissions and communicating with users. It names the roles, contact paths and decision points, and includes the commands and configuration keys used in each procedure. The organization reviews the runbook, runs a tabletop exercise against it and approves a final version. The output is a signed runbook with a version number and a review date.
Confirm the handover and ongoing testing
Your operations staff receive the retention matrix, configuration record, scan test record, backup inventory, restore log and runbook, and demonstrate they can execute the restore procedure without partner assistance. The team then sets a recurring restore test cadence and a process for re-running tests after each Nextcloud upgrade, which should move one major version at a time. Ask the partner to confirm in writing which handover items and retesting support are in the fixed scope and which fall under a retainer. The output is an accepted handover record.
Deployment pattern that keeps backups out of the sync path
A backup that a sync client can reach is a backup an infected laptop can encrypt. The cards below map the systems a ransomware-resilient Nextcloud deployment connects, and the access rules that keep the backup host separate from the endpoints that write to the share.
Nextcloud data directory
The data directory holds the user files, versions and trash bin contents that sync clients see. Mount it on the application server only, and keep it out of any network path that endpoints or a backup agent can write to. Confirm that no NFS, SMB or external storage mount exposes the same path to other hosts, because a writable second mount lets malware bypass Nextcloud entirely.
PostgreSQL or MariaDB metadata
The database stores file metadata, share records, version pointers and retention state. Without it, restored files cannot be matched to their owners or versions. Back up the database with a consistent dump taken alongside the data directory, and store that dump on the backup host, not on the sync share. Ask your partner how the two are kept in step during a backup run.
Antivirus scanner on the upload path
A scanner such as ClamAV, Kaspersky Scan Engine or an ICAP-compatible engine checks files as they arrive and runs background scans of stored files. Its job is to catch known payloads and to quarantine or delete infected files before they spread to other clients. It is a detection layer, not a recovery layer, so it does not replace the separate backup host. Confirm how signature updates reach the scanner in your environment.
BorgBackup host with restricted access
The backup host pulls encrypted, deduplicated archives from the Nextcloud server and should accept no inbound write from user endpoints. Where the backup tool supports it, use append-only or restricted repository access so that a compromised server cannot delete existing archives. Nextcloud All-in-One documents a BorgBackup-based backup option, so ask whether your partner uses it or a custom job, and who holds the repository passphrase.
Directory integration for restore rights
Restores should be a privileged action with named approvers, not a button every user can press. Nextcloud's LDAP app, along with its OpenID Connect and SAML backends, can map directory groups to administrative roles. Keep the restore group small, separate from general administrators where possible, and confirm that the backup host's own login uses separate credentials that are not stored on the sync server.
Network boundary for the backup path
The rule that matters most is that the backup host must not mount the sync share as writable from any endpoint. Restrict the backup network so that laptops and browsers cannot reach the repository or its SSH endpoint, and allow only the backup pull from the application server. Ask your partner to produce a firewall rule set and a test showing that a client on the user network cannot write to the repository path.
How the design changes for on-premises, private cloud and air-gapped sites
In a data center you own, the sync path, the database, the antivirus engine and the backup target usually sit on networks you control, so you can place the backup repository on separate storage and keep its credentials away from the sync servers. The main risk is that every layer is also a layer your team must patch. A ransomware-resilient design here depends on segmentation and on who can reach the backup repository.
- Backup repository isolation: Put the BorgBackup target on a host or storage tier that the file servers cannot write to with their everyday credentials, and restrict deletion of archives.
- Antivirus placement: Run the scanner on a separate host reachable only from the Nextcloud application servers, so the scan path does not share a failure domain with the file store.
- Database and file store backups: Back up the PostgreSQL database and the data directory together, and confirm the backup run is consistent with the Nextcloud maintenance mode steps in your runbook.
- Network controls: Limit outbound access from the application tier so a compromised server cannot push data to arbitrary destinations.
- Restore capacity: Confirm your storage has room to restore a full dataset alongside production, because restores often run during an incident.
Confirm with your platform team how your hypervisor snapshots interact with database consistency before you treat them as a recovery layer.
When the stack runs in a cloud account that your organization owns and administers, you gain elastic compute and object storage without giving a cloud provider access to file contents. Identity, key management and network policy remain yours. The ransomware exposure shifts toward credentials: an attacker with console access to the account can delete snapshots and buckets, so backup protection must be enforced at the account level, not only inside the application.
- Separate backup account or tenant: Place backup copies in a separate account or subscription with its own administrators and a narrow write-only role for the backup job.
- Object lock or retention settings: Confirm whether your provider offers immutable or locked object storage and how it applies to the BorgBackup repository you choose.
- Snapshot protection: Restrict deletion of volume snapshots to a break-glass group and alert on any change to retention policy.
- Key ownership: Keep backup encryption keys outside the account that holds the production data, so a compromised administrator cannot read or erase both copies.
- Egress and scanning: Check whether the provider's network services allow the antivirus engine to receive uploads without exposing the file store to the public internet.
Ask your provider and implementation partner to document which controls are enforced by the account and which depend on Nextcloud configuration.
On an air-gapped network, nothing arrives automatically. Antivirus signature updates, application updates, Nextcloud releases and backup copies all cross the boundary on approved media or through a controlled transfer process. Two things need confirmation with your chosen scanner: how it receives signature updates offline, and how often the signature set must be refreshed for your risk tolerance. The Nextcloud Antivirus for files app works with ClamAV, Kaspersky Scan Engine or an ICAP-compatible scanner, so the offline update path depends on which one you select.
- Offline signature updates: Confirm with the scanner vendor the supported offline update format, the source of signature packages and the verification steps before import.
- Media transfer controls: Scan and record every transfer of update packages and backup media, and keep a log of who carried each item across the boundary.
- Backup copies: Use removable or one-way media for copies that leave the enclosed network, and test that restores work from the media alone.
- Upgrade cadence: Plan Nextcloud upgrades one major version at a time, which means carrying each major release across the gap in sequence.
- Isolated restore environment: Keep a restore target that can be checked for malware before data returns to production.
Confirm the offline update process with the scanner and the air-gap procedure with your security team before the design is final.
Evidence an auditor or regulator asks for after an incident
This table lists the records an assessor or regulator is likely to request after a ransomware event on a self-hosted sync and share platform, the component that produces each one, and what the reader should confirm before an incident. Auditors decide whether the evidence is sufficient for their scope, so the goal is to have these records retained, timestamped and reviewable before anything goes wrong. Treat each row as a question to answer in advance, not a checkbox.
| Evidence | Produced by | What to confirm in advance |
|---|---|---|
| Version and trash retention settings | Nextcloud file versions, trash bin and Retention app configuration | Exported configuration showing retention periods, who can change them, and change history for the settings |
| Antivirus scan logs | Nextcloud Antivirus for files app with ClamAV, Kaspersky Scan Engine or an ICAP scanner | Log retention on the scanner host, signature update records, and how infected-file deletions were notified to users |
| Nextcloud audit log exports | Nextcloud audit logging and any forwarding to a central log platform | Whether logs cover file access, share changes and admin actions, and that exports can be produced for a defined date range |
| Backup job logs | BorgBackup jobs, including those bundled in Nextcloud All-in-One | Job success and failure history, repository integrity checks, and proof that backup copies sit outside the sync path |
| Restore test records | The restore procedure run by the operations team, with results written down | Dated test scope, who performed and reviewed it, what data was restored, and the time taken to reach a usable state |
| Signed recovery runbook | The partner-delivered runbook, approved by the client | Current version, approver names and dates, and the change record for each revision after go-live |
| Access and change records for the platform | Identity provider logs, directory group membership history and server configuration management | Whether privileged access during an incident is logged, and whether configuration changes are traceable to a named person |
What a restore test must prove before anyone trusts the backups
A backup is unproven until someone has restored from it on a schedule and shown that the result is usable. Until then, the backup job's green status tells you only that data was copied somewhere, not that a Nextcloud instance can be rebuilt from it. For this topic, the test has to cover the BorgBackup repository, the Nextcloud database dump, and the data directory together, because a restored file tree without matching database entries will not give users a working share. Ask your partner to run the restore into an isolated host, never over the production instance, and to keep the runbook steps that were actually executed rather than the ones written in advance.
The most important scenario is the one ransomware creates. Suppose a laptop with a sync client is infected, encrypted files are synced to the server, and the versions and trash bin behave as configured. The test should pick a point before the infection, restore the affected folder, and confirm that the restored files are the clean versions, not the encrypted ones that became the newest revision. Check that the restore point is older than the earliest encrypted write, that antivirus and retention settings did not remove the clean copies, and that the users who depend on the folder can open the files through the web interface and a sync client. Record any file that could not be recovered, because that gap is the real exposure.
Each test should produce a short written record: the scope restored (users, folders, database state and the date of the backup used), the time from decision to usable data, the integrity checks performed (such as comparing file counts, checksums or sample file hashes against a known list, and confirming that the database and file tree agree), and the named people who reviewed and approved the result. Agree the target recovery time with the business owners before the first test, so the measured figure has something to be compared against. The approvers should include someone from the data owner's function, not only the administrators who ran the restore. Confirm with your partner how these records are stored, because auditors will ask for them alongside the backup configuration.
Questions buyers ask before hiring help with ransomware-resilient file sharing
What does ransomware-resilient file sharing cost to implement?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main components are the people who design and build the platform, the storage and database capacity that holds file versions and trash bin contents, the backup target for BorgBackup repositories, antivirus engine and its updates, and testing time for restores. Some costs are one-time, such as design, configuration, integration and the first restore test. Others recur, such as storage growth, backup capacity, antivirus signature updates, platform upgrades and support. Ask any partner to split the quote into those components, state which ones are yours to buy directly, and name the assumptions about user count and data volume. If you are comparing editions, the Nextcloud pricing page lists published per-user rates for Enterprise tiers, with a 100-user minimum, which is one reference point for the software license line.
How long does a ransomware-resilient file sharing project take?
Duration depends on how many users, sites and existing file shares are involved, and on whether the platform is new or being hardened. A new deployment with versioning, trash retention, antivirus and backups takes longer than adding controls to a running instance, and restore testing adds time that teams often underestimate. Ask the partner for a phased plan with milestones: design of retention and backup policy, build and integration, scanning and alerting tests, a documented restore exercise and handover. No supplied timeline applies to your environment, so request the schedule in the written scope before work starts, and confirm which dates depend on your change approvals and hardware delivery.
What does our team need to provide before an engagement starts?
The partner needs accurate inputs before it can scope the work. Typical requirements include a list of user groups and expected growth, the hosting targets and whether they are on-premises, in your cloud account or in a data center, the identity source and directory design, the storage and database sizing you already hold, and the backup destination with its retention obligations. You should also supply your current recovery objectives, the owners who approve restore tests, and the change windows for upgrades. Name a security contact who can authorize test restores and an incident contact for escalation. Missing inputs usually become scope changes later, so ask the partner to list them as a written dependency in the quote.
Can an internal IT team build this without an implementation partner?
A capable internal team can build it, provided it has skills in the platform, Linux and container or VM operations, backup engineering, endpoint and malware controls, and restore testing. The harder part is not the initial configuration but keeping the controls working over time: monitoring scan jobs, confirming backup jobs complete, running restore tests on a schedule and documenting the result. Ask whether your team has capacity for those recurring tasks after go-live. A partner can fill gaps in design review, hardening, integration and runbook writing, or run a fixed-scope engagement that ends with documented handover. Either way, decide who owns each control before you start.
Will a Nextcloud upgrade break antivirus scanning or backup jobs?
It can, which is why upgrades should be planned as a controlled change rather than a routine update. Nextcloud does not allow skipping major releases, so each upgrade moves through one major version at a time, and the vendor advises backing up before every upgrade and disabling third-party apps until they are confirmed compatible. Antivirus integrations such as the Antivirus for files app depend on a working scanner engine, so check its compatibility and signature update path after each step. Backup tooling must also be tested after upgrades because database and configuration paths can change. Ask the partner to include a post-upgrade check of scan results, backup completion and a test restore in every upgrade plan. The Nextcloud upgrade manual is the natural starting reference for these steps.
What happens during a live ransomware incident on the file platform?
The first step is containment: isolate the affected endpoint from the network and suspend the sync account or client, so encrypted files stop propagating. Next, use the file version history and trash bin retention to identify clean versions, and confirm that backups in the separate BorgBackup repository are intact and not reachable from the sync path. Restore into a clean environment first, verify content, then reopen access in stages. A runbook should name who declares the incident, who approves restores, who contacts the forensics provider and how regulators or customers are informed. Ask a partner to write that runbook, rehearse it with your team and document the timings they achieved. No recovery time is promised here, and the actual duration depends on data volume and backup location.
What should a written quote for this work include?
A useful quote lists scope items, deliverables, assumptions, exclusions, client dependencies and acceptance criteria. Look for items covering retention policy design, version and trash configuration, antivirus integration and test files, backup design and encryption key handling, restore testing, runbook and handover, and a plan for upgrades. Check whether ongoing support, upgrades and continuous testing are priced as a separate retainer. Ask for the named deliverables and the evidence you will receive, such as configuration records and restore test results. Because DeployOpen works to a fixed scope agreed in writing before work starts, request that the quote define what is excluded, including third-party licenses and hardware.
Questions to put to an implementation partner on recovery design
Start by asking how versions, trash and retention are set for each library, because these settings decide how far back an infected laptop's damage can be undone. Ask which libraries get file versioning, how long deleted files stay in the trash bin, and whether the Nextcloud Retention app is used to delete data on a schedule. Ask who can change these settings and whether changes are logged. A strong partner will show you a per-library table of version counts, trash periods and retention rules, and will explain how a user who deletes or overwrites a shared folder can be restored without an administrator rebuilding it by hand.
Next, ask where antivirus sits in the upload path and in the background. Ask whether the Nextcloud Antivirus for files app is configured to scan on upload and in scheduled full scans, which engine it talks to (ClamAV, Kaspersky Scan Engine or an ICAP-compatible scanner), how signature updates reach the scanner, and what happens to an infected file already synced to other devices. Then ask where BorgBackup repositories live, who holds the encryption passphrase and repository keys, and whether any credential that can write to the sync path can also delete backup archives. Repositories on a separate host or storage account, with keys held outside the Nextcloud administrator role, are the design you should expect to see described.
Finally, ask how restore tests are run and recorded, and what the recovery runbook contains. Ask for a dated restore test that restores a sample library to a separate instance, verifies file counts and checksums, and records the time taken and the person who signed off. Ask how the runbook covers isolation of the affected account, revocation of sync clients, and sequencing of restores. Also ask how one-major-version Nextcloud upgrades are tested against backup jobs: a backup must be taken before each upgrade, and a restore must be proven on a copy of the upgraded version. Confirm the current supported release and end-of-life dates against the Nextcloud maintenance and release schedule before agreeing a timeline.
How DeployOpen scopes, builds and supports recoverable file sharing
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For ransomware-resilient file sharing, we start from a written scope that names the recovery targets, then build versioning, retention, scanning and backup separately so that one compromised laptop cannot reach every copy of your data.
How we scope
- Inventory which shares, teams and sync clients will hold data and which of them can be restored from backup.
- Agree in writing the version history, trash bin and retention settings for each class of data.
- Define the restore testing schedule, the recovery owners and the evidence your compliance team will need.
How we build
- Configure Nextcloud file versions, trash retention and the Antivirus for files app with ClamAV or another ICAP-compatible scanner.
- Set up BorgBackup jobs that write to storage with no sync client or user credential path into the file share.
- Harden the server, database and backup credentials so that routine user activity cannot alter or delete backup archives.
How we hand over
- Deliver a recovery runbook covering detection, isolation, restore sequencing and communication steps for your team.
- Document the backup schedule, retention periods, encryption keys and the location of every backup copy.
- Record the results of restore tests, including what was restored, how long it took and what needed correction.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
- Plan Nextcloud major version upgrades one step at a time, with a backup taken before each upgrade.
- Re-run restore tests after significant changes to storage, identity or scanning so the runbook stays accurate.
