I’m running Duplicati on a SMB server and I want to let users restore files from their own computers. The database is accessible over the network but for security reasons it’s write permissions are restricted.
Is it possible to add an option to perform restore commands using a read-only database?
Welcome to the forum @lhs_azevedo
The use case and topic title are a bit hazy to me. Is the idea that users keep the files they want backed up on the server, and then a privileged Duplicati backs up all locally, or does Duplicati do backups over SMB?
Backups where SMB is the source is not preferred for numerous reasons, but people do try them anyway. Some of the same issues occur (but more severely) if this is getting into SMB read of the DB (more later).
Assuming it’s central backup of local files, then restore could be done to local files, but the issue would be to keep users out of each others’ files. If you give access to the Duplicati GUI, users get access to all of it.
You can run multiple Duplicati to limit such sharing to groups (or even individuals) but it doesn’t scale well. Having multiple backup jobs in a single Duplicati is a bit better (if nothing else, a breakage doesn’t lose all). You also have a way to control backup file access on a fine-grained basis using some sort of permissions.
Maybe the reference to “read-only database” is asking whether having SMB access to the Duplicati DB is enough to allow some sort of restore. If one had that plus access to the backup files themselves, one can theoretically put files back together for restore IF everything will stand still and be consistent while working.
Currently Duplicati is not designed for simultaneous operations, e.g. simultaneous backups, or file restore during backup. There are discussions on both somewhere, but I’m not sure if they’re feature requests yet. Regardless, I think careful orchestration is required. If the idea is separate access, that’s probably unsafe.
As a side note, be careful about putting databases on networks. They contain secrets, so need protection.
If users currently have access to their backups as raw files, they can do a direct restore to create a partial temporary database using their own Duplicati copy to restore to their own machine. It’s a single-use thing.
How to refresh revisions imported from file and restore from another machine? is a similar wish of setting up a long-term ability to restore elsewhere, easily, safely, and with the latest version of source files. Some other questions have spoken of “collaboration” which is even further from what Duplicati is designed to do.
Doing “direct restore” in the middle of a backup that’s changing the files is hazardous, but maybe could be helped by timing, e.g. make sure no backups run when the users are restoring, or snapshot files for them.
To continue, please clarify the feature you wish. If read-only database can’t do it, maybe another way can. Short-term, this will have to be based on creative use of what’s there. Eventually, maybe design changes.
Interesting use case. Similar to using a restore-only version of cloudberry backup.
With a new restore-only switch, duplicati could be run by the restricted user and duplicati could make a copy of the SMB database file for local use and delete it when done. This removes the need to worry about handling attempted updates to the read only copy of the database.
Also in this case and for possible multiuser use, duplicate could be setting a field in the db as a flag to indicate a backup is running and/or look for any journal file which ikind of indicates a job is running.
Hi @ts678 and @BlueBlock .
First of all, thanks for your support.
Sorry, here are some details that I’ve missed on the first post:
We’ve scheduled some bat files on the Windows Server storage machine to backup over 7TB before dawn using Duplicati Command Line to our Google Cloud Storage cold bucket. I’ve been able to restore files from cloud running the Server on my desktop by pointing the database config to the server one. (avoiding those additional requests and processing for direct restores).
Next step was give some managers the ability to restore files (rare cases) on their own by setting up Duplicati on their machines the same way I did but without write permissions so they can’t accidentally delete on mess up the database.
From what I’ve seen there’s no need to write to it during restore except for operation history/logs. A simple solution would be a --readonly-database flag for the restore command.
This is an awesome software, really. I’m planning to contribute to the webapp on my spare time (no C# skills needed 
).
Sometimes people have trouble with SMB caching, and some behaviors might be SMB version-specific.
How To Corrupt An SQLite Database File might be bypassed by read-only, but note the network worries.
Both the server DB and the per-backup DB can be updated. The backup DB probably gets a little more, however the question would be whether it could do without any. Beyond the logs you see in the GUI, the internal operations are logged, such as the operation itself, and the remote operations to download files.
The --readonly-database reminds me of the –dry-run option which is vaguely described, and a bit buggy.
It might be workable but I think the main risk is concurrent activities tripping over some change. Not my call I believe. I wouldn’t be setting priorities on this (I’m not sure who does…) or writing the code. Duplicati is so decentralized that a lot of what happens is just due to some people (or someone) volunteering to develop it.
@BlueBlock has some good ideas on keeping things apart. It needs to be reliable, not just often reliable. Duplicati feels lots of pain from statistically rare things that only show up when the program hits wide use.
Thank’s for the note. It’s rough, but getting better…
Please join. Contributions of all sorts are welcome. I suspect sometimes collaborations between different people are good to collect all the needed skills (web work, C#, SQL, test, docs, etc. - a lot for one person).
What if you make a copy of the server database to the local machine for a user? It is then writable by Duplicati but the SMB files are still readonly and protected.
Oh, now I’ve got it.
I think I’m going this way, but making the copy on the server itself (db_copy.sqlite) after each backup and point users database to it…
Sure, will do!
I think you’ll want to copy it to each users machine. The Duplicati database is not designed for multiple users so it is unknown what issues users might encounter.
I’m still trying to figure out the plan here. Is it a central server with user directories and one huge backup?
From a personnel point of view, is the idea that managers can occasionally do restores for team people?
From a read-only point of view, be sure to protect the remote backup itself, not just the database. Having multiple databases in use all pointing to the same remote backup is a good way to kill the remote backup.
It sounds like the remote backup on the SMB is write protected so it is safe from users. Then I just think the server database needs to be copied for each user. Users can’t damage anything then.
Yes and yes, very occasionally.
We’ve setup an create/read only Service Account to authenticate on the cloud storage using rclone as backend.
BTW, that’s one of the reasons that we choose Duplicati, no cloud write delete permissions is a requirement. The batch command also sets the --no-auto-compat argument.
Defense against trojans gets into protection of the remote backup, sometimes for defense, sometimes for regulations. Even though the normal Duplicati way is create/read (after disabling compaction and retention deletes), there are some occasional situations where file delete might be attempted, e.g. if an upload fails partway, Duplicati will try to delete any pieces that got out. Possibly you’ll see some warnings as it tries to delete a file that’s missing. This may have gotten noisier in canary and experimental, so maybe I’ll pursue.
Because managers with restore privileges are trusted to see anyone’s files apparently (fixable if you divide by team), and because this all seems to live on the server (except for Google Cloud Storage backup files), easy solution is to give managers web access to Duplicati on server, and hope nobody hacks their way in.
Setting a certificate on Duplicati server might be good so you at least protect from network packet capture. Remote desktop to server would be less hackable (I assume), if policy allows that, then browse on server.
There’s a feature request somewhere for better administrative partitoning. It likely needs webapp work. 
Although it’s conceivable a manager could go into Database and delete it, it can in theory be (too slowly…) recreated from remote backup files, which unfortunately must also be done if Duplicati breaks its own DB. People sometimes backup their DB (ideally at least two copies in a row) in order to avoid doing Recreate. Putting in an old DB, though, will find it surprised by files it hasn’t seen. Repair can delete new files, but in your situation, I’m not entirely sure what it will do when faced with remote files it can’t delete. Please test.
Having an ever-increasing number of versions will also take its toll as the DB has more and more to track. This is another reason why smaller backups might be better. If something goes wrong, it’s a smaller fixup.
You’re somewhat protected against permanent remote damage by your access permissions, however a push of the backup button on a PC could cause partial file lists to upload due to permissions or no maps. Fortunately the next proper backup on the server would find all the blocks it needs, so no big new upload.
If you really want to put Duplicati onto manager PCs, getting a copy of the DBs (perhaps even by pull not server-push) would avoid the update-read-only-DB problem but worsen all-DBs-using-same-remote one. Large enough DBs may take awhile to copy, which favors smaller backups or your read-only DB request.
Interesting goal, and you have some setups that make it a little more possible compared to general case.
And this is the time when the prophecy of @ts678 is fulfilled.
We’ve split our backups in 4 groups, the biggest one database has over 5.4GB and is now out of sync with the cloud storage. Since the commands take a long time to execute, I will create another thread to share the situation and maybe get tips for repairing the db.
The idea of managers directly restoring the files was set aside for the time being.