Update:
4 small UI fixes
4.5 make the “selected item” shade a bit darker or a light green so it’s more apparent.
5-Feature requests
5.3 instead of status, show last successful run timestamp in green (or error in red) for each job.
(this is bc in a desktop the scheduler will not be always running)
5.4 If a job in a schedule is selected run just the selected job. (or display a “per job” run icon)
Feedback on the Dashboard:
Again - fantastic work. I believe this is the one missing piece that will make Duplicacy a de facto standard for folks I know (running a NAS, which is my use case). This could easily be made into a package for QNAP and Synology NAS app stores. A third-party app store has already bundled Duplicacy CLI for that purpose. However, I’m a big fan of docker for running web GUI interfaces so I don’t need to rely on the buggy or vulnerable Apache web server & PHP version that ships with the NAS.
If you are interested, one way around the default port is to use docker:
I few more bits of feedback for consideration after more uses :-
The naming of log files with on a prefix of “copy” or “backup” etc and then only the date and time can be a bit difficult to find the log file you want on a box with lots of different backup jobs. I think as a previous poster has suggested, it might be good to be able to name backup jobs, or at least “schedules” and use these names on the backup files to be able to quickly job to the log file you want if you are searching for log files.
As further reason to change the implementation of the ways you do restores is highlighted by a minor annoyance I have with something I have setup. I have a backup job to an onsite server. Then I run a copy job to the offsite server. Because I don’t have a “backup” job from the local server to the offsite server, there is no way for me to do a restore in the GUI, and you then need to go to the CLI. So based on that, and further to other comments above, I think it would much more sensible completely decouple backups and restores. From other backup software, the most standard way to do this would be to have a completely separate “Restores” top level option. If it was me, I would then allow people to browse all the configured “Storage’s” (I would also allow an additional storage to be configured at this point or at least point back to doing that at the “Storages” top level if required), and then browse all the backup IDs on that particular storage, irrespective if it has come from that machine or not, and then browse into the revisions etc. Of course you could implement the same thing from the “Storages” top level menu, which would offer the same functionality. But for me it seems counter intuitive to have to go to “Storages” to do a restore, and I suspect that Backup software needs to have “Restores” as a primary item Restores is a primary function of backup software, and backup is completely useless without restores. As a case it point, when I 1st started playing with the GUI, I though you had not yet implemented restores in the GUI yet, because I did not think to look for it under “Backups” and missed the significance in the tiny icon in backups that takes you to the restores option.
And of course, bonus marks for restores if it is possible to implement file revisions at the file level once you have drilled into the file, rather than having to search every revision from the top down. Interim step might be to allow file history from the GUI to be able to see the dates the file changed
I could believe it might be something for a future version, but for GUI users who have used backup software that allows you to choose what you want to backup and exclude from a directory tree you can drill into which has tick boxes next to the things you want to backup and/or exclude, it is hard to go back to methods similar to current implementation used in Duplicacy. I guess this is further complicated in Duplicacy’s CLI and “Repository” based approach. But ideally for simple non technical GUI users, I think it would be simpler if they couple create jobs based on frequency and destination and place all the directories in that backup strategy in the 1 job.
Anyway, the work so far looks fantastic, so keep up the good work. And I appreciate there are lots of reasons you have done things the way you have that I have not even thought of. But hopefully these end user insights are useful.
Just tried it out, first time, on a Mac. Had to “chmod +x” the executable, but then it ran without a hitch. Might be better to distribute it as a zip, which might preserve the x bit, too.
It would be nice if you’d (optionally) use the native file browser. The one that’s now used is not user friendly compared to what macOS offers.
Hi,
I have just started using Duplicacy and am using the Web Edition on Linux.
Some feedback I have:
Features that would be great:
That’s all my feedback/suggestions for now :>
Thank you very much for working on the Web based GUI.
It great good so far!
Regards
pdaemon
This has been fixed in the latest beta version.
That would be better, but how do you set the times and the intervals?
I plan to fix this in a later release.
These have been all fixed in the current beta, which should be available sometime next week.
A general option in config would be nice
.
But I also like the option to do it on-demand.
Hi gchen,
Thanks for fixing and including suggestions in the next version!
In regards to the check jobs, they could run in the background at certain intervals (global setting), but can be overwritten with your own intervals if required (on-demand) as bkeeper suggests?
I look forward to the new version next week.
I also have another question…
How do I go about restarting the duplicacy server service? I couldn’t find a CLI option.
Just a kill -9? and run the cmd again? An option in the GUI to restart the service would be good 
Thanks Alot!
Regards
pdaemon
To restart the Duplicacy services you’ll need to run the Windows Service Manager (enter services in the run dialog) and then right click the Duplicacy service to invoke the menu and select Restart.
Hi gchen,
I’m using Linux :> How is the service restarted on the backend when you make changes in the “Settings” in the GUI?
Sorry for getting off topic. If this is not simple, I’ll post something in a different section of the forum.
Thanks.
Regards
pdaemon
After you click the Save button in the Settings page, it should restart by itself. If it doesn’t then this is a bug.
Yeah, it does restart.
I’ll get back to you with any other feedback once you release the new version.
Thanks again.
Another question about the Web GUI.
I have setup a copy to B2 Backblaze and have read that having multiple backup threads running at once can be better for data throughput to B2.
What is the default number of threads that are used when setting up a B2 backup in the GUI? Will there be a way to change the number of threads used per backup job?
Thanks.
Cheers pdaemon
I guess we can customize the CLI command at each step, (also for restores?) but right now there is no reference info.
But we should make it easier to customize the CLI command that gets run at each step:
With placeholder examples or even a drop-down menu or control widgets for usual command modifiers (such as threads).
The default number of threads is always 1. In the web GUI you can set the options for each job separately so you can use -threads n if the command supports it.
Hi gchen,
OK thanks. I’ll give that a go.
Any update on when the next version is coming out? 
Cheers pdaemon
I’ll make it available this evening.
The new beta is up: Duplicacy Web Edition 0.2 Beta is now available.
May we close this thread and use the new one?
