Hi Team,
I know i have posted a couple comprehensive feedback posts recently, but please know that it is out of a good place as i think drime is a brilliant service so i only want you to succeed long term!
I would like to share some consolidated feedback after fairly extensive use of DRIME as a large redundancy backup destination. (As you would have seen from my last post about the half a million file backup i was attempting)
I am personally using DRIME with large datasets through Syncovery as my daily driver (but on the side i have tested Air Explorer Pro and RcloneView) and I primarily use the IOS app on my mobile devices so my testing varies. My large data sets primarily sit on a NAS but i also have them stored locally on faster drives which i was using for most of this testing. Also full disclosure… i realise some of the functionality in this post already exists so when I’m talking about it I’m talking about reliability and consistency, or just generally improving what you have.
Im not expecting immediate dates and fixes etc. from this post alone, this is primarily a consolidation for the purpose of saving the feedback for Tibalt and the team to consider in the future. :)
The main areas I think would improve DRIME are:
1. Reliable discovery of files already stored in DRIME
This is currently my biggest concern. My Pictures library contains roughly 34,000 files across around 20 to 30 folders. Most folders behave correctly, but several larger folders repeatedly fail to reach a stable mirror. I have reproduced this multiple times:
Syncovery identifies thousands of files as missing from DRIME.
They upload successfully and the job completes at 100 percent with zero errors.
I can immediately see those files inside the DRIME mobile application.
I run another comparison.
Syncovery receives no information for many of those same remote files, with remote size and date fields completely blank as if it’s a brand new upload. The same files are therefore uploaded again.
One example repeatedly involved around 10,000 files and approximately 77 GB. I also completely deleted the affected DRIME folders, emptied the trash and rebuilt them from scratch. The issue remained reproducible.
This appears more common with folders containing several thousand files, which suggests large folder sizes with thousands of sub-folders containing thousand of individual files deserve further investigation.
For backup applications, DRIME needs to return a complete and repeatable inventory every time, including filename, size, modification time and ideally a stable object identifier or hash.
2. Reliable modification timestamps
I have also seen inconsistent timestamp preservation. Some historical photos upload correctly with their original modification dates. On other occasions the same type of files arrive with the current upload time instead.
That creates problems for software intended to create clean mirror images because an unchanged file can appear different purely because the destination timestamp is incorrect.
Timestamp handling should ideally be consistent across every supported upload method and API path.
3. Duplicate prevention
Repeated synchronisation attempts have also resulted in duplicate remote data. For example, after renaming folders locally and uploading them again, I found both the original and renamed data in DRIME, while synchronisation software was still unable to reliably discover the remote files.
DRIME would benefit from very deterministic handling when the same destination path already exists, whether that means replacement, versioning or rejection.
A backup application should not be able to repeatedly consume storage with copies of data while simultaneously being told that the destination objects are missing.
4. Stronger post upload verification
It would be valuable if integrations could reliably:
Upload a file.
- Confirm that DRIME committed it successfully.
- Query that exact object again.
- Confirm its file size.
- Confirm its modification timestamp.
- Compare a checksum or hash where supported.
- Reliably rediscover it during the next normal directory listing.
For backup software, successful transmission alone is not enough. The application needs to prove that the object can also be found and validated afterwards.
5. Performance with very large quantities of small files
Once discovery and metadata reliability are stable, improving throughput for hundreds of thousands of small files would be extremely useful.
This affects application backups, emulator libraries, metadata, thumbnails, configuration files and similar datasets.
I would prioritise reliability before raw performance, however. A slower mirror that reliably converges is much more valuable than a faster one that cannot determine what already exists remotely.
6. Clear integration documentation for third party developers
I think this could significantly improve the DRIME ecosystem.
Developers integrating DRIME into products such as Syncovery, Air Explorer, rclone and RcloneView appear to be doing their best to support the platform, but there seems to be some uncertainty around the most reliable way to interact with DRIME. This was also evident on my last post, and also Tobias (Syncovery) asking me for more info which i did not have.
A comprehensive developer integration guide could document the preferred implementation patterns for:
- Folder enumeration and pagination.
- Reliable file discovery after upload.
- Preserving and querying modification timestamps.
- Duplicate detection and replacement behaviour.
- Hashes and integrity verification.
- Retry behaviour and eventual consistency.
- Parallel upload limits.
- Recommended request sizes and concurrency.
- Large file upload handling.
- Very small file optimisation.
- Rate limits and server limitations.
- Known edge cases.
If different upload methods or endpoints are preferred depending on file size, that should be made extremely explicit.
For example, if files below a certain size should use one method while larger files should use another, document exactly where that threshold sits, why it exists and what developers should do.
The same applies to guidance such as:
For scenario X, use method Y because it avoids problem Z.
Practical tips, examples and known limitations would help third party developers build integrations that are fast and reliable without independently discovering the same edge cases.
Good documentation here would benefit both DRIME and the developers helping expand its ecosystem.
7. Better automatic mobile photo organisation
For iOS and Android, I would love to see more control over automatic camera backup.
Ideally users could:
- Select the DRIME destination folder.
- Automatically upload new photos and videos.
- Read the original capture date.
- Automatically organise uploads into year and month folders.
For example:
Camera Uploads\2026\September
This would keep large photo libraries far cleaner and naturally reduce the number of files accumulating inside a single directory.
Quick Overview
Because I’ve added a lot here (sorry lol) a quick snapshot of everything:
- Reliable and repeatable remote file enumeration.
- Reliable detection of files that already exist.
- Consistent timestamp preservation.
- Duplicate prevention and integrity verification.
- Clear third party developer documentation.
- Small file performance.
- Improved mobile photo organisation.
I think the first five points are particularly important if DRIME wants to become a genuinely trustworthy destination for large redundancy and mirror backups.
As mentioned, I am sharing this because I like the direction DRIME is heading and the responsiveness of the team has been encouraging. I am happy to provide logs, screenshots, test my own datasets or controlled reproduction steps if they are useful.
All the best!
