Give it a little while. I’m troubleshooting problems, which may be related to 220.127.116.11, completely breaking my backup
Alright, it turns out to not be a bug but just the fact that “Linux default filters” are actually applied now, because of Fix default filters in server / UI by tygill · Pull Request #3023 · duplicati/duplicati · GitHub, removing anything in
/var which was definitely not my understanding of the filter.
I’d vote for a “let it bake a while longer” option.
I don’t undestand. Does duplicati-18.104.22.168_canary_2018-02-12-x64.msi install only *.exe?
C:\Program Files\Duplicati>dir *.exe
Том в устройстве C не имеет метки.
Серийный номер тома: NNNN-NNNN
Содержимое папки C:\Program Files\Duplicati
31.01.2013 14:42 19 456 Duplicati.CommandLine.BackendTester.exe
31.01.2013 14:42 37 888 Duplicati.CommandLine.Decrypter.exe
31.01.2013 14:42 94 720 Duplicati.CommandLine.exe
31.01.2013 14:43 1 456 640 Duplicati.exe
31.01.2013 14:42 33 280 Duplicati.Library.SharpRSync.exe
31.01.2013 14:42 53 760 Duplicati.Library.Snapshots.exe
6 файлов 1 695 744 байт
0 папок 60 348 280 832 байт свободно
My setup options avaible this:
I want to use D2 as service.
I believe it’s the same installer as with the other releases. You should be able to get it to run as a service
Do you see “Duplicati.WindowsService.exe” among my 6 files? I downloaded file from this page: https://github.com/duplicati/duplicati/releases
If it didn’t extract from the installer, try to reinstall it or just download the zip file and copy the missing files over.
In additional at home I upgraded D2 from 22.214.171.124 from 17 and before from 16. But Duplicati.WindowsService.exe has version 126.96.36.199. For me it’s strange and may be ver 17 and 19 doesn’t contains this files.
of course, no. I attached screenshoot my D2 setup.
Do you really think that it’s normal for new user to install and download missing file?
Honestly, it’s a canary build, if the user isn’t comfortable troubleshooting issues the user should be using a more tested release like the beta or experimental release.
I’m sure someone would like to help, but I think you’ll have more luck getting help if you open a new topic instead of posting on the release note page.
Thank you. But I don’t need help now)) So, you’re answered to subject question))
It shouldn’t be promoted to the experimental channel!
OK guys. If issues need to be fixed, please give me a list if github issues that we should include for the next experimental.
I took the liberty of tagging Revise default backup filters · Issue #3030 · duplicati/duplicati · GitHub to the experimental milestone because the filter is much too strict now.
Besides that I think we’re looking at:
- The issue with
--retention-policythrowing not-that-user friendly
warningserrors after upgrade (because they’re now mutually exclusive) Release: 188.8.131.52 (Canary) 2018-02-11
- More testing of
--retention-policyand preferably some Unit tests to verify edge cases etc as it’s hard to test many different cases with a feature that depends on time passing
- Problem selecting “Smart backup retention” in the Web UI “Smart backup retention” causes error: Retention value must be more than 5 minutes · Issue #3010 · duplicati/duplicati · GitHub
Additionally, @kees-z and I were discussing two alterations on
--retention-policy that I think would make sense to add before retention policy was released to everyone to avoid confusion if added later. The first being a semantic
U notation for
U:1M instead of writing
1W:U instead of
1W:0s). And the second being a
K notation for
keep as there are some things you can’t do like
1M:1D without risking ending up with just a single backup if your machine is offline for longer than a month. New retention policy deletes old backups in a smart way
And we should have a couple of people running windows try and replicate the above problem with Duplicati Server not upgrading when using the windows installer. Not worth much pushing updates if no one gets them
Let me summary this:
Default filters were fixed. We are concerned that they might filter too many files and folders now. We should revise the rules, to make sure, noone who has activated any system filter is missing files after an upgrade. Good point.
We are still testing the retention policy and would like to introduce two more options. One covers the entire future to avoid rules like 100Y:1M. The other is there to make sure that there is always a minimum number of backups before the deletion kicks in. Suggested notations are: U:1M and K:30. I agree on the testing. I don’t think we need U and K for an experimental release (unless someone gets this implemented quickly).
Issue #3010 was reported once. Nobody could reproduce and the user did not give any feedback so far. I would prefer to ignore this.
Windows server: Is there an issue on github?
PS: I see that you are very dedicated to chase some of the newer issues. We still have a lot potential to improve Duplicati for many people. E.g. the update notification comes in through various channels and if you choose to update from the about screen, there are multiple progress bars. This is something that deserves our attention. But not for the next experimental version. If you like, we could start a discussion about this as the next major thing.
I think this one may be related to the issue with --keep-time and --retention-policy throwing not-that-user friendly errors when combined. They may be the same issue.
Not that I know of. I haven’t had the opportunity to try to replicate as I just saw it here on the forum. Maybe skip it and deal with it if it turns out to be a problem?
I think I can get Never mind, it’s a bit more tricky. The
U in with like 2 lines of code just translating it to
0s and before running the retention policy method since it’s just semantics.
K is very cool, but I also fear it may be quite a bit more work to implement. If we’re just aiming to ship quicker so we can get to next experimental release sooner, then it might not be terrible to just ship it as is once we handled the showstoppers
I’m pretty sure it contains the files as I just (2 hours ago) did a duplicati-184.108.40.206_canary_2018-02-12-x64.msi install on a new machine (English Windows 10) without issue.
Following the above linked service process (including using Duplicati.WindowsService.exe) also worked just fine.
My guess is there’s an edge case with how an MSI update (not to be confused with a GUI update) is handled vs. a fresh install.
Thanks for testing
Agreed. I think historically trying to squeeze that one last tweak in is what slows down releases.
Heh, it wasn’t actually a test. A client’s backup drive filled using Windows backup so I decided to switch them to Duplicati.
And yes, I know it’s canary - and yes, I still feel confident it will work as needed.