Deleted cloud files are not always gone immediately. This practical checklist explains how to recover cloud files from Google Drive, Dropbox, and OneDrive, how to handle sync conflicts or ransomware, and what to check before a recovery window closes.
Overview
Cloud file recovery usually depends on where the file was deleted, how it was synchronized, and which retention or backup features are available on the account. A file may be in a trash or recycle folder, represented by an older version, stored in another user’s shared folder, or available through an administrator restore process.
Before changing anything, record the file name, original location, approximate last-known date, owner, and the device or account involved. Avoid repeatedly moving, renaming, or synchronizing folders while investigating. Those actions can make it harder to distinguish an ordinary deletion from a sync conflict or a malicious change.
Use this order of operations:
- Confirm that the file is genuinely missing rather than filtered, renamed, moved, or offline.
- Search the provider’s trash, recycle, or recently deleted area.
- Check version history and other copies, including shared folders and local devices.
- Ask a workspace administrator about administrative restore options.
- Preserve evidence and stop synchronization if ransomware or unauthorized access is suspected.
For a broader platform comparison, see our guide to recovering deleted files from Google Drive, Dropbox, and OneDrive. Provider labels and recovery limits can change, so use the current in-product instructions for the account you are restoring.
Checklist by scenario
Google Drive
- Open Google Drive using the account that owned or managed the file.
- Search by file name, type, owner, and location. Check whether the item was moved to another folder or shared drive.
- Open the Trash area and look for the item. If it is available, use the restore action and confirm its original location.
- If the file exists but its contents changed, open version history where supported and identify a suitable earlier version.
- For a work or school account, contact the Google Workspace administrator promptly. An administrator may have additional recovery paths, particularly when content was deleted by a user or removed from managed shared storage.
If you manage a workspace, document the affected user, file owner, deletion time, shared-drive location, and any relevant audit information before attempting a bulk restore. The Google Workspace administrator guide provides a separate recovery-focused workflow.
Dropbox
- Sign in to the correct Dropbox account and search for the file by name or extension.
- Check deleted files or the relevant recovery area. Availability can depend on the account, file location, and the provider’s current retention rules.
- Use version history when the file remains present but was overwritten, corrupted, or changed unexpectedly.
- Check shared folders and team spaces. Another member may have moved, renamed, or deleted the item.
- If a local Dropbox folder is involved, pause syncing before experimenting with copies. Preserve an unaffected copy of the local folder if one exists.
A Dropbox recovery request should include the exact path, file name, approximate date, and whether the issue affects one file, a folder, or many synchronized devices. This distinction helps separate normal deletion from a broader account or device problem.
OneDrive and Microsoft 365
- Check the OneDrive recycle bin while signed in as the affected user.
- For work or school content, ask the Microsoft 365 administrator to check available recycle-bin and restore paths, including the relevant SharePoint or shared-library location.
- Use version history when the file is present but has been overwritten or encrypted.
- Review the OneDrive sync client for paused synchronization, sign-in errors, conflicted copies, or a different account.
- If several files changed at once, stop sync and investigate before restoring a large batch.
OneDrive recovery can involve both the user’s personal file area and a team site or SharePoint library. The Microsoft 365 recovery guide covers those administrator-level paths separately.
Ransomware, unauthorized deletion, or account takeover
Do not treat widespread file changes as routine deletion. Disconnect or pause affected sync clients, avoid opening suspicious files, and preserve a clean copy of available evidence. Secure the account from a trusted device by changing the password, enabling or reviewing multifactor authentication, revoking unfamiliar sessions and app access, and checking sharing permissions. Then contact the provider or workspace administrator.
Recovery from ransomware is safer when you identify a known-good restore point rather than simply synchronizing the damaged state across more devices. Use the security-incident session and access checklist alongside your file recovery plan.
What to double-check
- Correct account: Personal, work, school, and guest accounts can have similar names but separate files.
- Ownership and location: A shared file may be owned by another person, a team space, or an organization.
- Time zone and timestamps: Activity times may appear differently across devices and administrative logs.
- File identity: Compare the extension, size, modified date, and, where appropriate, a cryptographic hash with a known copy.
- Recovery scope: Decide whether you need one file, a folder, or a complete account restore. Test a small recovery first when possible.
- Retention limits: Trash, version history, administrator restore, and backup retention are separate features. Their availability can vary by account type and current provider policy.
- Privacy: Do not upload sensitive documents to an unknown recovery tool. Review permissions, data handling, and deletion practices before using any third-party service.
A sync service is not automatically a complete backup. Sync can reproduce deletions, corruption, or encrypted files across devices. Maintain an independent, tested backup for important data and keep at least one recovery copy separated from everyday synchronization.
Common mistakes
- Waiting while assuming the provider will retain deleted content indefinitely.
- Emptying the trash or deleting duplicate copies before confirming which version is needed.
- Restoring directly into a live synchronized folder during a suspected ransomware incident.
- Searching only by file name instead of checking shared locations, alternate accounts, and renamed files.
- Installing unverified “recovery” software or giving a third party broad cloud credentials.
- Overwriting the original evidence by repeatedly signing in, syncing, or running cleanup tools on an affected device.
If a suspicious message led to the deletion or exposure, do not follow links in that message. Verify the provider through its known website or application, then review our guidance on checking whether a cloud storage email is legitimate.
When to revisit
Review this checklist before seasonal planning cycles, account migrations, major folder reorganizations, and changes to your cloud tools. Revisit it immediately after a security incident, a new administrator policy, or a change in backup architecture. Provider interfaces, account plans, retention controls, and administrator workflows can change, so confirm the current recovery options before relying on a remembered procedure.
Make the process actionable by scheduling a small recovery test: select a non-sensitive sample file, delete or version it in a controlled location, and verify that an authorized user can restore it. Record the result, retention assumptions, administrator contacts, and the location of an independent backup. For a reusable operational version, keep the cloud file recovery checklist with your incident-response documentation.
If a file is still missing after checking trash, versions, shared locations, local copies, and administrator options, stop making changes and preserve the remaining evidence. At that point, provider support or a qualified recovery professional may be appropriate, especially when the files are business-critical, encrypted, or connected to an account takeover.