Everything you need to know about the product and how it works.
Can't find the answer?
Please, chat with our friendly team.
Cloud-to-cloud backup is a service where data from one cloud platform is backed up to another cloud-based storage environment. In essence, it's a Backup-as-a-Service offering that creates a secure copy of your cloud data in a separate cloud location, so it can be restored if needed.
Storing data in the cloud doesn't make it immune to loss. About one-third of cloud data loss is due to user errors (accidental deletion or overwriting), and other risks include malicious deletions, hackers, sync glitches, or service outages.Cloud providers have redundancy for themselves but often cannot recover your data once it's permanently deleted on your end cannot recover your data once it's permanently deleted on your end (for example, after a recycle bin is purged. A cloud-to-cloud backup keeps independent copies of your data to restore those lost or corrupted files, providing an extra layer of protection.
Cloud-to-cloud backup works by connecting to your cloud applications (via secure APIs or credentials) and periodically copying your data to a separate cloud storage. The backup service will snapshot your data and store it safely in the cloud snapshot your data and store it safely in the cloud so that a point-in-time version can be recovered later. Because the backup runs entirely in the cloud, you don't need any hardware - the provider manages the storage and infrastructure.
Security is a top priority in cloud backups. Reputable providers protect data with strong encryption both in transit and at rest – using AES-256 encryption for stored data and SSL/TLS for data transfer. Your backup data is stored in hardened, secure data centers with robust physical and network security. Our solution also uses unique encryption keys per customer and per dataset, ensuring that even if one key were compromised, it couldn’t decrypt other data. In short, your data is encrypted and safeguarded so that only authorized access (you or those you designate) can read it.
FileScience stores your data in Amazon Web Services by default. If geography is a relevant, we do allow you to choose the geographic region of storage to meet data residency or compliance needs. For example, you might choose to keep backups in the US, EU, or Australia data centers. The data is typically replicated within that region for durability (multiple copies within a data center or across zones). By selecting a region, you ensure your backup data stays in an approved location (helpful for GDPR and other local regulations).
Yes. A critical advantage of having independent backups is protection against ransomware or malicious corruption. Our Cloud-to-cloud backups are immutable, meaning once data is backed up, it cannot be altered or encrypted by malware on your end. If ransomware encrypts files in your primary cloud account, you can restore clean versions from the backup, effectively rolling back to a safe state. Additionally, our systems don’t execute files when copying them, so malware-infected files are stored inertly and won’t spread through the backup platform. In short, backups let you recover from ransomware by retrieving uninfected copies of your data.
Yes, our backups are automated and we perform daily backups by default (for example, every night) without manual intervention. We also offer a high frequency backup, allowing you to back up multiple times per day (e.g. 4x a day) for more frequent protection. The initial setup is done once, and then backups happen automatically at the set frequency, ensuring new and changed data gets protected regularly.
We keep backups indefinitely (with “unlimited storage” so you don’t worry about older backups), but the retained time can be customized.
Our backups maintain multiple versions. Each backup run captures a snapshot of your data at that point in time without overwriting the previous one. This means if you modify or delete a file, you can still retrieve the earlier version from a prior backup. Versioning allows point-in-time recovery - you can roll back to last week's email or yesterday's document version. Essentially, backups are non-destructive: new backups add to the archive instead of replacing older backups.
You can perform granular restores, letting you retrieve individual items - such as one email, a specific document, or a single user's data - without having to do a full restore of everything. This item-level recovery is very useful; for instance, if one file is accidentally deleted, you can just restore that file. Of course, you also have the option to restore larger sets (like an entire mailbox or folder) if needed, but you are not forced to roll back or recover the whole system for one item.
Restoring data is very straightforward via the backup service's interface. You would log in to the backup dashboard, find the datafind the data you want, and then initiate a restore. The service will then provide a download.
Pricing is based on a per GB or per user model, depending on the cloud. This tend to be a more cost effective structure. You can find our quoting tool here: https://dashboard.filescience.io/quote
We include the storage costs in our per-user pricing – meaning the backups are stored in our cloud do not create additional costs for you.
We do provide no-cost egress, but egress that exceeds XXGB per month, are subject to a $X.XX fee per GB.
Restoration speed are generally instant but have a 24-hour SLA for recovery. Most times file size is the variable here.
Our dashboard will alert and an e-mail will be sent providing detailed reporting if a failure was to happen.
Backups will not disrupt daily usage, and they are engineered to be as efficient as possible with bandwidth.
Yes. Scalability is a key benefit of cloud-based backups. These services are designed to scale on demand, whether you're protecting 10 users or 100,000, a few gigabytes or many exabytes.
Built-in retention (like recycle bins or litigation hold in Office 365) is helpful, but it's not a complete backup solution. Legal holds preserve data for eDiscovery, but they have limitations - for example, Microsoft's litigation hold has mailbox size quotas (~100 GB) and won't retain data if a user's license is removed. It also doesn't provide easy restoration, just preservation. Relying solely on these can give a false sense of security. As one analysis put it, using holds in place of backup can be “risky” because data might still be lost when employees leave or if errors occur. A cloud-to-cloud backup keeps independent, restorable copies of data (physically separate from the primary service), which is the safest approach for general recovery. In summary, retention features and holds are not designed for point-in-time recovery or full protection - they complement but do not replace having a true backup.
When an employee leaves, you'll likely remove their account from the primary cloud service - but your backup can still retain that user's data. Cloud-to-cloud backup solutions will keep the departed employee's backed-up emails, files, etc., under an “inactive” or archived status. Notably, one best practice is to save costs by removing the SaaS license while still retaining the backup archives in case of litigation or knowledge transfer. You can also perform cross-user restore - for instance, restore the ex-employee's mailbox into a new user's mailbox if someone takes over their role. In short, employee departure doesn't mean backup deletion; you maintain the data for as long as needed.
Syncing (or cloud storage services like OneDrive/Dropbox) is not the same as backup. Sync keeps files consistent across devices - if you delete or change a file, that change syncs everywhere (including deletions). A true backup, by contrast, maintains historical versions and separate copies. With replication alone, any corruption or deletion on the source can immediately propagate to the replica, whereas a backup can be used to recover the earlier intact data. In short, cloud sync is great for accessibility and collaboration, but it is not a trustworthy backup solution. Backup ensures you have an independent copy that isn't automatically changed when the source changes. This distinction is crucial: for protection against accidental or malicious changes, you need backup, not just sync.