How to Set Up Automatic Cloud Backup for Your Password Database

A password database is one of the most important files on your devices. Losing it means losing access to every account it contains. Yet many people rely on a single copy of their database with no backup strategy. Cloud sync solves part of this problem by keeping copies on multiple devices, but sync is not the same as backup. Sync propagates changes – including accidental deletions and database corruption. A proper backup strategy preserves historical versions of your database so you can recover from any failure scenario.

This guide covers how to set up automatic cloud backups for your KeePass password database, including versioning, redundancy, scheduling, and the often-overlooked step of testing your restore procedure.

Sync vs. Backup: An Important Distinction

Before diving into backup strategies, it is critical to understand why cloud sync alone is insufficient.

Cloud sync keeps files identical across devices. When you edit your password database on your phone, the change propagates to your laptop, your tablet, and any other synced device. This is useful for access and convenience, but it has a dangerous property: destructive changes also propagate.

If your database file becomes corrupted (a rare but possible event during a crash mid-save), that corruption syncs to all your devices. If you accidentally delete the database, the deletion syncs everywhere. If malware encrypts your files with ransomware, the encrypted (ransomed) file replaces the good copy on all synced devices.

Backup preserves point-in-time copies of your file. If something goes wrong with the current version, you can restore a previous version from an hour ago, a day ago, or a month ago. Backups protect against:

• Accidental deletion
• File corruption
• Ransomware and malware
• User error (accidentally saving over your database with bad data)
• Software bugs that damage the database

The ideal setup uses both: cloud sync for convenient multi-device access, and automated backups for disaster recovery. For an overview of keeping your database safe, see our guide on backup strategies for password databases.

Built-In Cloud Provider Versioning

The simplest form of automated backup is file versioning built into your cloud storage provider. When enabled, the provider automatically keeps previous versions of your files whenever they change.

iCloud Drive Versioning

iCloud Drive maintains previous versions of files for up to 30 days. On macOS, you can access previous versions through Finder:

1. Right-click the file and select “Browse All Versions,” or open the file and choose File > Revert To > Browse All Versions.
2. A Time Machine-like interface shows available versions.
3. Select a previous version to restore.

On iOS, iCloud Drive versioning is less accessible. The Files app does not expose version history directly. To access older versions, you would need a Mac or the iCloud.com web interface.

Limitation: iCloud versioning is best-effort and not guaranteed. Apple does not document exactly how many versions are retained or under what conditions older versions are pruned. For a file as critical as a password database, relying solely on iCloud versioning is insufficient.

For iCloud-specific sync setup, additional considerations apply to ensure versioning works reliably.

Google Drive Versioning

Google Drive keeps up to 100 versions of each file for 30 days. You can access version history through the web interface:

1. Right-click the file in Google Drive.
2. Select “Manage versions.”
3. View and download any previous version.

Google Drive also allows you to pin specific versions to prevent them from being automatically deleted after 30 days. This is useful for creating known-good snapshots of your database that persist indefinitely.

Tip: After making significant changes to your password database (adding many new entries, reorganizing groups, changing the master passphrase), pin the current version in Google Drive. This creates a permanent restore point.

For setup details, see our Google Drive sync guide.

Dropbox Versioning

Dropbox retains file versions for 30 days on the free plan and 180 days on Dropbox Plus. An extended version history add-on extends retention to 10 years.

1. Log in to dropbox.com.
2. Navigate to the file.
3. Click the three-dot menu and select “Version history.”
4. View, download, or restore any previous version.

Dropbox’s 180-day retention on paid plans is the longest default among the three major providers and provides a meaningful safety net.

Building a Multi-Layer Backup Strategy

Cloud provider versioning is a useful first layer, but a robust backup strategy should not depend on a single provider or a single mechanism. Here is a multi-layer approach:

Layer 1: Cloud Sync with Versioning (Automatic)

Store your primary database in a cloud-synced folder (iCloud Drive, Google Drive, or Dropbox). This gives you multi-device access and automatic versioning. Every time you save the database, the provider retains a copy of the previous version.

This layer protects against: recent accidental changes, database corruption detected quickly.

Layer 2: Secondary Cloud Provider (Automatic or Scheduled)

Copy your database to a second cloud provider. If your primary cloud account is compromised or experiences an outage, you have an independent copy elsewhere.

Options for automating this:

• Cross-cloud sync tools: Services like MultCloud or rclone can automatically copy files between cloud providers on a schedule.
• Folder automation on macOS: Use Automator or a shell script triggered by launchd to periodically copy the database file to a second cloud-synced folder.
• Manual but scheduled: Set a weekly calendar reminder to copy the database to a second location. Less elegant, but effective if you follow through consistently.

This layer protects against: primary cloud account compromise, primary provider outage, primary provider data loss.

Layer 3: Local Offline Backup (Scheduled)

Maintain a copy of your database on local storage that is not connected to the internet. This could be an external hard drive, a USB flash drive stored in a secure location, or a NAS (network-attached storage) device on your local network.

Automation options:

• macOS Time Machine: If your database is in a cloud-synced folder that is also on your Mac’s local disk (which it typically is), Time Machine automatically backs it up along with everything else. Time Machine keeps hourly backups for 24 hours, daily backups for the past month, and weekly backups until the disk is full.
• Scheduled rsync: A cron job or launchd task running rsync can copy the database to an external drive on a schedule.
• Backup applications: Tools like Carbon Copy Cloner or ChronoSync can create scheduled backups to external drives.

This layer protects against: ransomware (offline copies cannot be encrypted by malware), cloud provider account lockout, internet-dependent scenarios.

Layer 4: Off-Site Physical Backup (Periodic)

For maximum resilience, keep a copy of your database in a physically separate location – a family member’s home, a safe deposit box, or an office safe. Update this copy monthly or quarterly.

This might seem excessive for a file that is measured in kilobytes, but consider the consequences of total loss: every password, every account, every secure note, gone. An encrypted USB drive stored off-site is cheap insurance.

This layer protects against: fire, theft, natural disaster, any scenario that destroys all devices and local backups simultaneously.

Automating Backups on Apple Devices

macOS Automation with launchd

Create a backup script that copies your database to a secondary location with a timestamp:

#!/bin/bash
SOURCE="$HOME/Library/Mobile Documents/com~apple~CloudDocs/PanicVault/database.kdbx"
BACKUP_DIR="$HOME/Backups/PanicVault"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p "$BACKUP_DIR"
cp "$SOURCE" "$BACKUP_DIR/database-$TIMESTAMP.kdbx"
# Keep only the last 30 backups
ls -t "$BACKUP_DIR"/database-*.kdbx | tail -n +31 | xargs rm -f 2>/dev/null

Schedule this with a launchd plist to run daily (or more frequently). Each run creates a timestamped copy and prunes old backups to prevent storage bloat.

iOS Automation with Shortcuts

Apple’s Shortcuts app can automate file operations on iOS and iPadOS:

1. Create a new Shortcut.
2. Add a “Get File” action pointing to your database in iCloud Drive.
3. Add a “Save File” action to save a copy to a second location (a different iCloud Drive folder, or a Dropbox/Google Drive folder via their Files app integration).
4. Optionally rename the file with the current date.
5. Set the Shortcut to run on a schedule using Personal Automation (e.g., every morning at 8 AM).

iOS Shortcuts automation has limitations – some automations require user confirmation before running – but it provides a workable solution for periodic backups.

Testing Your Restore Procedure

A backup you have never tested is a backup you cannot trust. At least once per quarter, perform a complete restore test:

1. Locate a backup copy of your database from at least one week ago.
2. Copy it to a temporary location on a device where your password manager is installed.
3. Open the backup database with your password manager using your master passphrase (and key file, if applicable).
4. Verify the contents – spot-check several entries to confirm they are readable and correct.
5. Delete the temporary copy after verification.

This test validates the entire chain: the backup file exists, it is not corrupted, your passphrase works, and the data is intact. If any step fails, you have found a problem while you still have time to fix it.

Common failures discovered during restore testing:

• Backup file is zero bytes – the sync or copy process failed silently.
• Passphrase does not work – you changed your passphrase but backed up a pre-change copy, or the key file is missing.
• Database is corrupted – the file was modified or partially overwritten during sync.
• Wrong file backed up – the backup script points to the wrong path.

Each of these is recoverable if discovered during a planned test. Any one of them is catastrophic if discovered during an actual emergency.

Versioning Strategy for Password Databases

Password databases have a unique versioning characteristic: changes are usually small (adding or modifying a single entry) but each version represents the complete state of all your credentials. This means:

Every version is independently valuable. Unlike source code, where you typically only care about the latest version, each version of a password database is a complete, self-contained set of credentials. An older version might contain a password you changed and forgot, or an entry you accidentally deleted.

Storage cost is minimal. A typical KDBX file is under 1 MB. Keeping 365 daily backups uses less than 365 MB – negligible on any modern storage medium.

Retention should be long. Because each version is small and independently useful, there is no practical reason to aggressively prune old backups. Keep daily backups for at least 90 days and monthly backups indefinitely. The storage cost is trivial, and the recovery value is high.

What to Do When Something Goes Wrong

If you discover your current database is corrupted, accidentally deleted, or otherwise unusable, follow this recovery procedure:

1. Stop syncing immediately. Disable cloud sync or disconnect from the internet to prevent a corrupted file from propagating further.
2. Identify the most recent good backup. Check cloud provider version history first (fastest to access), then local backups, then off-site copies.
3. Restore the backup to a temporary location. Do not overwrite any existing files until you have verified the backup.
4. Open and verify the restored database. Confirm the data is intact and your passphrase works.
5. Replace the damaged file. Once verified, replace the corrupted database with the backup. Re-enable sync.
6. Re-enter any changes made since the backup. If the backup is from yesterday, you may have added or changed entries today that need to be re-entered.

If your cloud account itself was compromised, see our guide on what happens if your cloud account is hacked for specific steps to take.

Backup Checklist

Use this checklist to evaluate your current backup strategy:

• Primary database is stored in a cloud-synced folder with versioning enabled
• A copy exists on at least one additional cloud provider or storage location
• A local offline copy exists (external drive, NAS, or Time Machine)
• An off-site physical copy exists and is updated at least quarterly
• Backup automation is configured and running on a schedule
• Old backups are retained for at least 90 days
• Restore procedure has been tested within the last 90 days
• Master passphrase and key file (if used) are documented in a secure, offline location for disaster recovery

A password database without backups is a single point of failure for your entire digital life. The encryption that protects your passwords is only valuable if the encrypted file survives. Automated cloud backups, combined with local and off-site copies, ensure that your database – and the hundreds of credentials it contains – is resilient against any single failure, whether technical, human, or environmental.