Duplicati, ZyXEL WiFI DFS, Database

I got so seriously dissatisfied with Duplicati 2 reliability, I had to write a fully automated backup testing. Which runs weekly. Because otherwise I can't be sure that the backups work. Well, that's anyway something what I should have done earlier. I was always on my mind, but now it was finally the time to get the job done. Let's see the successful restore percentage was around 50%. Which is of course totally something ridiculous! I so much knew it! It's so broken! Restore and test says data set is broken, but repair and purge-broken-files says it not broken. Quite a dangerous trap. - Basically it's totally and absolutely broken, until fix is provided. - It really shouldn't be this complex the get the data structure "fixed" by removing (while fixing) or skipping (while restoring) invalid data. As well as making sure, no new invalid data is being added / created to the backup set.
ZyXEL's DFS made me wonder! Really? DFS radar detection on channel 36? - Yeah right. Also why they're changing channel so often, and also changing from non-DFS channel to non-DFS channel when the detection triggers. My guess is that the code is written so that when DFS event is triggered, it just assigns new random channel from non-DFS channels set of (36, 40, 44, 48). And I mean truly random, because it can assign same channel which was already being used. It's clearly very bad code without doing any sanity checks. Depending on the DFS trigger implementation, it can be completely separate module, which just detects radar pulses on any channel and triggers the event. Therefore, all the logic which would make this process sane in some way is completely missing. The implementation is so bleeped, that it makes me wonder, if they're trolling on purpose. Related log just for lulz: 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 36 - May 11 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 48 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 44 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 36 - 20:44:15 [SYSTEM]: WLAN[5G], BSS(rai0) DFS found radar and chang channel to 36 - Please note that the chang is what it says in the logs, not my mistake this time. Also if you bothered to look at the timestamps, it's very obvious that all of those channel changes happened within one second. This is also probably the reason why 5G WiFi completely freezes from time to time. kw: radar avoidance, 5 GHz, 802.11h, U-NII, ZyXEL, WiFi, WLAN, NBG6515
Never write your own database. Nice and solid article. It's always about the requirements. Just as the articles like never use something for something. It depends just as the examples as using SQL database as queue, in some cases, the usage is so low, and adding extra technologies will just make things a mess. As well as storing blob data directly into file system as files, instead of using database. I started with attitude, that this must be a bad article. But after all it was a great article. Also not all the features of full featured DBMS system are required in all the situations. Something like cost of MS SQL Server can be devastating for light projects. And how do you run that on low end Linux device? Sometimes the readability of the data is important .That's why I often use INI / JSON files for data. Anyone can read, modify and save that data, without any special tools and without any special skill set. Persisting state that way is simple, reliable and easy to change, when required. Especially in cases where amount is data is relatively small and operation most of the data is replaced anyway.

2019-10-13