P3R wrote: ↑Tue Sep 03, 2019 7:58 am
@Bob Zelin,
- Not all existing jobs from previous versions will work after the upgrade. I had a versioned job that failed. Making sure conversions of existing jobs work should be one of the first and most important things to test I think.
- It look like they broke backward compatibility with older HBS versions. I'm not completely sure about this yet, it may change when support get back to me on #1.
- Creating a versioned backup job now forces the use of QuDedup. Existing converted jobs will still work the way they used to but I can't change anything in them or create new jobs working the way they used to. One consequence of this is that everyone that have used versioned backups will have to reinitialize that and throw their old versioned backups (which could be 6 or more months of backup) away when they need to change anything! In my opinion one of the greatest advantages with the previous HBS versions was that it didn't have a proprietary backup format locking the customer in. That have now changed...
- They've now limited the allowed characters in job names and if you use one of the now banned characters in a converted job you now need to change the name if you want to change anything else in the job.
#1 and possibly #2 are very bad. #3 is a disaster and #4 is time consuming and annoying.
I'm reluctant to change anything now in HBS while I wait for support to get back to me so I haven't used it very much but on the plus side I noticed that scheduling have been improved and that's great.
Of course the addition of QuDedup is a fantastic improvement for many users but make it optional and
don't take existing functionality away from us!
Facing #1, #2 and #4 above. I agree on all points. My understanding is that QNAP is aiming for customer lock-in. All these problems migrating jobs from v2 to v3 just shows that they don't do proper testing before they push their apps to consumers.
IPv6 issue
Another issue I've been experiencing. In case the NASes are on a dual stack IPv4/IPv6 networks (either local or remote networks), backups are a hit or miss. My understanding is that they develop their apps without proper handling of IPv6 addresses (by the way myqnapcloud receives and publishes AAAA updates via DDNS).
@QNAP: A quick hack around this issue until you fix your apps is to provide additional DNS addresses for IPv4 only or IPV6 only. An example for clarity follows:
Current situation (fictional addresses)
Code: Select all
nslookup myhost.myqnapcloud.com
Non-authoritative answer:
Name: myhost.myqnapcloud.com
Addresses: 2a02:101:1011:101:101:1111:1111:1111
92.49.13.191
Suggested solution is to add ipv4 and ipv6 only DDNS entries. For example, myqnapcloud could provide A records only for myhost-ipv4.myqnapcloud.com and AAAA records only for myhost-ipv6.myqnapcloud.com, in addition to the A and AAAA records provided for myhost.myqnapcloud.com
Code: Select all
nslookup myhost-ipv4.myqnapcloud.com
Non-authoritative answer:
Name: myhost-ipv4.myqnapcloud.com
Addresses: 92.49.13.191
nslookup myhost-ipv6.myqnapcloud.com
Non-authoritative answer:
Name: myhost-ipv6.myqnapcloud.com
Addresses: 2a02:101:1011:101:101:1111:1111:1111
this way we can use myhost-ipv4.myqnapcloud.com in our remote backup setting to avoid the IPv6 mishandling of the apps.