Release: 2.0.2.19 (Canary) 2018-02-12

canary

#1

2.0.2.19_canary_2018-02-12

  • Updated translations
  • Rebuilt stylesheet

This is otherwise the same as 2.0.2.18_canary_2018-02-11.


#2

Thanks.

Could you re-apply the translations with the next Canary? Two weeks ago I resolved a nasty typo in the Dutch translation, which doesn’t seem to have it made to the last versions.
“This week” should be translated to “Afgelopen week”, not “Deze wek”.

image

image


#3

The 2.0.2.19 patch notes says updated translations and compiled css, so it should be there.

Is there some kind of delay between between translations being suggested and them being applied in an update?


#4

Translation was fixed 14 days ago:
image
It’s also part of the .PO file at GitHub (line 2223).


#5

Hmm, I must admit I don’t know how they worked. I submitted a few minor translations on the translation website like 7 months ago but I never paid attention to when they made it in.


#6

Just a FYI, I’ve experienced some problems with backups on my Ubuntu server after applying 2.0.2.18/19. It looks like permission issues where my entire /etc and most of my /var/www folders are missing from every backup since last night when I upgraded.

I’m not sure it’s related to the actual release but I’m rolling back to 2.0.2.17 to test if it’s somehow version specific or if it’s just a bad upgrade. The service showed up as running as root and no warnings were given about permission issues, which is why I’m a bit confused.

Edit: It’s looking more and more like a permission issue. Same thing happens with 2.0.2.17. Interestingly it counts 200GB and then when it finishes counting it immediately goes down to 100GB “to back up”. But since it happens on 2.0.2.17 it’s not an issue with 2.0.2.18/19.

Edit2, I spoke too soon, 2.0.2.17 actually included all the files once it finished and I opened the restore view to check… Reinstalling 2.0.2.19 now to try again.

Edit3, I still cannot back up those folders under 2.0.2.19 BUT if I create a new job backing up only /etc it backs it up with no problems. So my issue is specific that one backup on 2.0.2.19… Super strange…


Should 2.0.2.19 be promoted to the experimental channel?
#7

When you export both backup jobs to commandline, do you spot any differences that could cause this problem or are related somehow to the items in the changelog?
(please don’t let it be something related to --retention-policy syntax…)


#8

I added all the advanced options from my existing backup (except email… too lazy) to the new test backup, including retention policy, so I do not think it’s related to retention policy :slight_smile:

I’m in the middle of rebuilding the database, so I have to wait for that to test more backup runs…

The biggest difference is that I have some exclude filters on the existing backup

--default-filters=Linux 
--exclude-files-attributes="temporary,system" 
--exclude="*.db-wal" 
--exclude="*.db-shm"

And it could be a filtering issue if it’s not a permission issue. A filter issue would also explain why there are no warnings. Missing files are the purpose of filters, after all.


#9

Maybe #3023 is involved somehow?


#10

My database rebuild just finished (and a backup run completed but still missing /etc)

I just disabled --default-filters=Linux and --exclude-files-attributes="temporary,system" and started a new backup run


#11

I’m pretty sure #3023 is indeed the reason, as before that pull, the default filters weren’t actually active on backups invoked via the UI. And I see that /etc/* and /var/* are indeed excluded by the Linux filters (thinking about it, I’m not sure whether or not they should be).


#12

It indeed was. That’s what I get for toggling options with no descriptions in the frontend :slight_smile:

I don’t know, but it should definitely be listed when you enable the option. I expected the filters to include stuff like .swp files or .log files. However 90% of my important data is in /var/www or in /etc, so I will definitely not be using the Linux filter going forward.


#13

Displaying the filters in the UI isn’t a bad idea.

Most of the filters come from this StackOverflow thread, which in turn comes mostly from Crashplan’s default set. It might not be a bad idea to go back over those and see if there’s anything that shouldn’t be there.


#14

Hmm, that’s interesting. My Duplicati settings more or less mirror my crashplan settings and they both run side by side.
Either my Crashplan client doesn’t care about those rules, or Crashplan overrides those rules if you specifically select the folder.


#15

Digging into that post more, it references this bit of documentation on Crashplan’s site. It looks like there are some exclusions which are never backed up (and can’t be overridden), which includes things like $RECYCLE.BIN, System Volume Information, pagefile.sys, various browser caches, /tmp, /proc, etc. There’s also a second set of folders which are backed up, but are hidden by default in the restore view, and this is the set that includes /etc, /var, /bin, and others.

That approach actually makes a lot of sense, and for the default filters in Duplicati, we should probably not be excluding the ones that Crashplan only hides (maybe with a few exceptions, e.g., .Thumbs.db and (?i)./NTUSER.*).


#16

Ah, okay. I think we should add changing this as a milestone for experimental :slight_smile: Should 2.0.2.19 be promoted to the experimental channel?

I can’t be the only one who would be affected by this now that the filters actually work :wink:

I created an issue to track it: Revise default backup filters · Issue #3030 · duplicati/duplicati · GitHub