I second that! … 20 Characters
Can stopping the backup in the Web UI translate to Control=>C on the CLI version in Windows so when the initial backup is started again, it won’t start over/check files. I’m not really sure which it does since I see my upload BW in use but the storage destination isn’t going up in usage.
This can be a real problem for large backup sources since you’d need to leave your computer on for days just to get the first backup.
I found an issue in the restore web UI.
In one of my repositories/backups I have a folder called “slide scan project”. If I use duplicacy list -r 1 -files from the appropriate repository in .duplicacy-web to list the contents of the snapshot revision I can confirm that this folder exists in the backup. However, in the web UI restore tab, this folder is instead just called “project” (which isn’t a folder that actually exists in either the backup storage or in the local repository). The contents can be listed, but it’s not showing the correct folder name.
Perhaps the web UI doesn’t like folders with two spaces in the name?
edit: here are some additional details from a minimal example (from mac, instead of my “production” linux box). For some reason even single space directories aren’t handled correctly in this example either.
Repository contents
$ find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
.
|____.DS_Store
|____one space
| |____1
|____i have two
| |____2
|____nospace
| |____0
What is shown in the restore tab
I updated the links in the first post to point to the 0.2.10 release. Most bugs reported in 0.2.8 here should have been fixed (if it is stated in the change logs).
2 Likes
Can you add a verbosity setting? It isn’t possible to set it in the options of the repo in the webui. Also setting enum-only doesn’t work either in the current log level.
Instead of using variables, wouldn’t it be better if the web UI supplied all of the available options and a field on what they should be set to? Like a dropdown or text box for available options?
Are there any particular reasons to not start a new topic for every beta release? I would recommend doing that in the future.
1 Like
Graphs curve fitting are sometimes getting ridiculous: Perhaps linear interpolation would be sufficient instead? Making smooth data out of discrete quantity (count) does not make sense anyway…
Screen Shot 2019-01-16 at 11.54.09 AM.png
4 Likes
For that matter, having a Y axis with non-integer graduations is counter-intuitive and makes the graph unnecessarily hard to read when the quantity is (presumably) always an integer…
I’d say a simple bar graph would give a much better visual representation of the data.
4 Likes
I’ve nuked .duplicacy-web and re configured everything to start from clean slate.
Clicking on the progress bar to see the log sends to URL like this:
http://127.0.0.1:3875/show_log?name=backup-20190116-122104.log&tail=true
which never completes loading.
that files does exist thought
alexmbp:~ alex$ find ~/.duplicacy-web -name backup-20190116-122104.log
/Users/alex/.duplicacy-web/logs/backup-20190116-122104.log
Edit. Actually, it did load the page, only after the backup run completed. Perhaps open/share issue. Duplicacy-web shall open log files in shared mode, so that it can read while it is being open and still written to.
1 Like
-
Entering storage path on the server as
//Backups/duplciacyends up beingsftp://alex@tuchka.home.saspus.com///Backups/duplicacy. Note three slashes. -
Cannot edit storage after creating it. Configuration parameters (e.g. ssh_key_file) in the duplicacy.json is encoded/encrypted so I cannot edit it there either.
Duplicacy shall ether validate the storage parameters by attempting to connect and upload a file or allow to edit the storage if the user configured it incorrectly.
Also, no need to encrypt path to key file… or was that the key itself? if so, it is wrong - I may need to change key I pointed the duplicacy at the creation stage, for example when it expires. -
The
~is not understood by the CLI2019-01-16 12:21:04.610 INFO SSH_PUBLICKEY Failed to read the private key file: open ~/.duplicacy/id_rda_duplicacy: no such file or directory alexmbp:~ alex$ file ~/.duplicacy/id_rda_duplicacy /Users/alex/.duplicacy/id_rda_duplicacy: PEM RSA private key -
Please move default locations for “Temporary directory” and “Log directory” to outside of user’s Home. On MacOS there are dedicated folders for stuff like that:
~/Library/Cachesand~/Library/Logs. Yes, user can change that (and I do), but default values should adhere to target OS app development guidelines.
I also would vote for an option to email only upon error (or a weekly/monthly email option with a summary of backups and statuses for that period).
1 Like
+1. This is a generally accepted and preferred practice — to report only failures to minimize noise and interruptions. I don’t want to receive and process notifications to know that everything is fine. “Life is good” is a default. Failure will become less noticeable due to cry wolf effect. If I’m drowning in hourly “Backup completed successfully” emails Ill develop tolerance and won’t notice “Backup burnt in flames” email.
Let’s have separate options whether to send email on success and on failure. Synology does that and I’m infinitely thankful for that. Some software at work does not, so I have elaborate systems of filters to land these messages straight to trash.
Synology configuration for illustration:
1 Like
Not sure if this is a known issue (I’m new to Duplicacy), but in the Storage screen the charts aren’t rendering any data (Size / Revisions / Chunks). Tried Safari and Crome, same issue:
@joe can you view the page source to see if there are any chart data? They should be like this:
Chartist.Line('#sftpChartSize', {
labels: [ "Dec21", "Dec22", "Dec23", "Dec24", "Dec25", "Dec26", "Dec27", "Dec28", "Dec29", "Dec30", "Dec31", "Jan01", "Jan02", "Jan03", "Jan04", "Jan05", "Jan06", "Jan07", "Jan08", "Jan09", "Jan10", "Jan11", "Jan12", "Jan13", "Jan14", "Jan15", "Jan16", "Jan17", "Jan18", ],
series: [
[ 25717374976 , null , null , null , null , null , null , null , null , null , 25890390016 , 25909264384 , 25974276096 , null , 26020413440 , 26071793664 , null , null , null , null , 26186088448 , null , null , null , null , 26708279296 , 26742882304 , 26742882304 , 26742882304 , ],
[ 8298430464 , null , null , null , null , null , null , null , null , null , 8333033472 , 8352956416 , 8352956416 , null , 8381267968 , 8381267968 , null , null , null , null , 8429502464 , null , null , null , null , 8434745344 , 8434745344 , 8434745344 , 8434745344 , ],
[ 12358516736 , null , null , null , null , null , null , null , null , null , 12495880192 , 12495880192 , 12560891904 , null , 12577669120 , 12630097920 , null , null , null , null , 12695109632 , null , null , null , null , 13213106176 , 13247709184 , 13247709184 , 13247709184 , ],
[ 2283798528 , null , null , null , null , null , null , null , null , null , 2283798528 , 2283798528 , 2283798528 , null , 2283798528 , 2283798528 , null , null , null , null , 2283798528 , null , null , null , null , 2283798528 , 2283798528 , 2283798528 , 2283798528 , ],
[ 4399824896 , null , null , null , null , null , null , null , null , null , 4399824896 , 4399824896 , 4399824896 , null , 4399824896 , 4399824896 , null , null , null , null , 4399824896 , null , null , null , null , 4399824896 , 4399824896 , 4399824896 , 4399824896 , ],
[ 1090519040 , null , null , null , null , null , null , null , null , null , 1090519040 , 1090519040 , 1090519040 , null , 1090519040 , 1090519040 , null , null , null , null , 1090519040 , null , null , null , null , 1090519040 , 1090519040 , 1090519040 , 1090519040 , ],
]},
Is there any documentation/write up that explains the relation between CLI, GUI and Web edition versions?
I have two GUI licenses, running 20+ jobs. Are those jobs from Windows GUI “compatible” with Web edition or I would have to recreate them if I want to use Web edition?
@gchen yes the page source does show chart data similar to what you quoted.
I had this problem in .8 and it persists with .10, and it the chart doesn’t render in both Safari and Chrome.
Here’s the source code snippet:
Chartist.Line('#Duplicacy.WasabiChartSize', {
labels: [ "Jan05", "Jan06", "Jan07", "Jan08", "Jan09", "Jan10", "Jan11", "Jan12", "Jan13", "Jan14", "Jan15", "Jan16", "Jan17", "Jan18", "Jan19", ],
series: [
[ 133997527040 , 284708306944 , 486752124928 , 617943662592 , 716865273856 , 824981848064 , 848934469632 , 941080182784 , null , null , 998911246336 , 998918586368 , 1046934978560 , 1046934978560 , 1046934978560 , ],
[ 133990187008 , 133990187008 , 133990187008 , 133990187008 , 133990187008 , 140911837184 , 140911837184 , 140911837184 , null , null , 140911837184 , 140911837184 , 188928229376 , 188928229376 , 188928229376 , ],
[ null , null , null , null , null , 472784044032 , 472784044032 , 472784044032 , null , null , 472784044032 , 472791384064 , 472791384064 , 472791384064 , 472791384064 , ],
[ null , null , null , null , null , null , null , null , null , null , 516253810688 , 516253810688 , 516253810688 , 516253810688 , 516253810688 , ],
]},
{
axisY: {
labelInterpolationFnc: function(value) {
return formatBytes(value);
},
},
chartPadding: { left: 40, top: 20, },
lineSmooth: Chartist.Interpolation.cardinal({
fillHoles: true,
}),
low: 0,
});
Chartist.Line('#Duplicacy.WasabiChartRevision', {
labels: [ "Jan05", "Jan06", "Jan07", "Jan08", "Jan09", "Jan10", "Jan11", "Jan12", "Jan13", "Jan14", "Jan15", "Jan16", "Jan17", "Jan18", "Jan19", ],
series: [
[ 1 , 1 , 1 , 1 , 1 , 3 , 3 , 3 , null , null , 4 , 5 , 6 , 7 , 8 , ],
[ 1 , 1 , 1 , 1 , 1 , 2 , 2 , 2 , null , null , 2 , 2 , 3 , 3 , 3 , ],
[ null , null , null , null , null , 1 , 1 , 1 , null , null , 1 , 2 , 2 , 2 , 3 , ],
[ null , null , null , null , null , null , null , null , null , null , 1 , 1 , 1 , 2 , 2 , ],
]},
{
chartPadding: { left: 40, top: 20, },
lineSmooth: Chartist.Interpolation.cardinal({
fillHoles: true,
}),
low: 0,
});
Chartist.Line('#Duplicacy.WasabiChartChunk', {
labels: [ "Jan05", "Jan06", "Jan07", "Jan08", "Jan09", "Jan10", "Jan11", "Jan12", "Jan13", "Jan14", "Jan15", "Jan16", "Jan17", "Jan18", "Jan19", ],
series: [
[ 27138 , 56912 , 97746 , 123977 , 143484 , 164648 , 169321 , 187191 , null , null , 198182 , 198186 , 207958 , 207958 , 207958 , ],
[ 27136 , 27136 , 27136 , 27136 , 27136 , 28673 , 28673 , 28673 , null , null , 28673 , 28673 , 38445 , 38445 , 38445 , ],
[ null , null , null , null , null , 94391 , 94391 , 94391 , null , null , 94391 , 94395 , 94395 , 94395 , 94395 , ],
[ null , null , null , null , null , null , null , null , null , null , 101247 , 101247 , 101247 , 101247 , 101247 , ],
]},
{
axisY: {
labelInterpolationFnc: function(value) {
return formatNumber(value);
},
},
chartPadding: { left: 40, top: 20, },
lineSmooth: Chartist.Interpolation.cardinal({
fillHoles: true,
}),
low: 0,
});
$('a[data-toggle="tab"]').on('shown.bs.tab', function (e) {
target = $(e.target).attr("href");
$(".tab-pane").each(function() {
name = "#" + $(this).attr("id");
if (name != target) {
return;
}
($(this)).find('.ct-chart').each(function (i, e) {
e.__chartist__.update();
});
});
})
$(":input").on("input", inputChanged)
});
Quick update… I was able to resolve my storage graph not rendering.
It turns out, Duplicacy doesn’t like periods in storage names. I had my storage set to “Duplicacy.Wasabi” but when I renamed it to “Duplicacy-Wasabi” and ran a check, the storage graph now renders successfully.
Maybe Duplicacy should restrict periods in storage names, or alternatively fix the code so that a period doesn’t break the graph? Either way, removing the period fully fixed my issue.
3 Likes
This has the potential to create a bunch of ugly long filenames but it may in fact be necessary, as though it’s not specifically stated above and I swear I saw mention of this before but cannot find it…
Parallel backups are creating log files with the same name and thus only one survives.
When I click on or hover over one of the two parallel backup jobs, they link to the same log URL. The other log file seems to be missing.
Regarding parallel jobs… I’m wondering if Duplicacy shouldn’t approach this feature in a slightly different way.
When I started using this feature a day or so ago, I tried enabling it on just one job - expecting it to run in parallel to all others - but it doesn’t. You have to click a second job (or re-order the schedule so the parallel one is last?). Now this may sound reasonable, but it may not provide the sort of parallelism that you might want and need, i.e. parallel jobs running between different physical disks only.
Let’s say I have the following repositories:
C:/Users/Darren
E:/Darren
E:/Blah
E:/Progs
I want the first job to run in parallel to the other 3, but the three on E should run sequentially.
At the moment, if parallel is unticked, that job won’t run if any other Duplicacy instance is running - regardless of if that other instance was meant to be parallel or not. However, I think that should change to not run unless another instance is a parallel job. i.e. it should look to see if any Duplicacy processes are flagged as parallel and ignore them.
Or maybe there’s a better way. Maybe the tickbox could be tri-state: ticked, unticked, greyed out (which means indifferent, as described above).
To be honest, the main benefit of running parallel imo is to make more efficient use of disk I/O, and so long as jobs on the same physical hard drive don’t run in parallel, but those on different physical disks can, perhaps the parallel tickbox should be moved from individual jobs to a single tickbox on the schedule.
Then Duplicacy can work out on its own which jobs should be parallelised.