This is a real-world incident response case study involving a personal encrypted cloud backup system using rclone and IDrive E2. In April 2025, multiple buckets seemingly disappeared from both the IDrive web interface and rclone CLI. This document outlines the diagnosis process, lessons learned, and technical context behind the event.

• OS: Gentoo Linux with OpenRC
• Backup Tool: rclone with rclone crypt
• Scheduler: OpenRC cron
• Locking Mechanism: flock
• Storage Provider: IDrive E2
• Architecture:
  • Encrypted buckets via rclone crypt
  • Each job scoped to its own bucket
  • Non-destructive backups using rclone copy
  • One isolated rclone sync job

• Only 2 out of ~8 buckets visible
• No deletions shown in the IDrive GUI audit logs
• One bucket (anki-backup) still fully functional

• Ran rclone lsd idrivee2: → confirmed missing buckets
• Verified correct region/endpoint settings
• Access keys were scoped and secure
• Verified rclone copy jobs were used (non-destructive)

• All other rclone jobs were using flock -n and had been silently blocked since April 15
• No sync, purge, or delete commands were active aside from one isolated job
• Confirmed local source directories were populated (no accidental wipe)

• On April 19, rclone mount showed all buckets and files as expected
• Buckets disappeared suddenly between the night of April 19 and morning of April 20

IDrive support confirmed:

Dear Chris M,

This message is in reference to ticket number: ID808975363

Thank you for bringing this to our attention.

We identified a temporary backend inconsistency that affected the visibility of some buckets and access controls. The issue has now been resolved, and we can confirm that your data remains fully intact and secure.

To provide additional technical context: Our system architecture involves multiple components that independently manage and store user data. To optimize request performance, a centralized cache layer maintains metadata about buckets and objects to accelerate certain types of user queries. During the incident, the centralized cache server experienced a communication glitch and was unable to retrieve metadata for certain buckets from the underlying storage nodes that host the actual data. This resulted in temporary inconsistencies in bucket visibility, although the backend data itself was never impacted.

Could you please recheck and confirm if you are now able to view your buckets and access your data without issues?

We apologize for any confusion or inconvenience this may have caused. If you observe any lingering inconsistencies or unusual behavior, please feel free to reach out — we are monitoring the system closely and are here to assist.

Thanks, Your IDrive Support Team

• Preserved system state before tampering
• Conducted methodical, forensic-style troubleshooting
• Used shell tools, logs, and rclone with precision
• Clearly documented findings to provider support
• Avoided re-uploading or overwriting potentially intact data

• Avoid silent job failures with better lock handling/logging
• Enable persistent logs for OpenRC systems
• Use systemd or OpenRC service wrappers with better observability (optional)
• Implement alerting or monitoring on rclone lsd results
• Capture lock file metadata before cleanup — /tmp/*.lock files confirmed flock failure but were lost before screenshots could be taken due to temporary directory cleanup

This incident, while personal, reflects core values of professional IT and security practice:

• Perseverance under pressure
• Calm incident response
• Evidence preservation
• Communication with vendors
• Root cause analysis

Real-world failures—even in personal systems—can demonstrate operational maturity and investigative skill.

flock -n /tmp/anki.lock rclone copy /home/user/.local/share/Anki2 IdriveEncrypt:anki-backup

flock -n /tmp/anki.lock \
  bash -c 'rclone copy /home/user/.local/share/Anki2 IdriveEncrypt:anki-backup \
  >> ~/.rclone/logs/anki-backup.log 2>&1 || echo "Backup failed at $(date)" >> ~/.rclone/logs/errors.log'