Today, I wanted to try the QSync functionality of my QNAP NAS to be able to move away from Dropbox. Oh boy…
Although QSync is labeled “beta”, I thought this is more of a marketing maneuver than a strong indication for an “absolutely useless piece of software”.
So I download the .dmg image of the Mac client for QSync and install the QSync client. Well kinda installed. As soon as I wanted to configure the email server the entire thing dies. OK, another try without the email server configured and I made it to the end of the setup procedure.
So there it is – the new QSync folder. Like the one you get when you use Dropbox. “Nice”, I thought.
I copied over 2 folders from my Dropbox and … nothing happens. Not what I would’ve expected.
The menu bar icon somehow tries to indicate me that it is most probably still syncing – at least that’s what I’m guessing.
So I browse to the Web File Manager to check out the remote QSync folder and there I see a single folder with no content.
Sure, a total of 5MB worth of data can take a while on a 1 Gbit/s LAN.
After waiting another minute or so the icon turns to something that looks very similar to the Dropbox icon when everything is synchronized. With the only difference that with QNAP QSync this is not the case. Nope.
When I pull up my network monitor to see if there is something going on in transfer-land, I can in fact see that QSync is transferring data at 2.5Kbit/s! WTF!?
So I google “qnap qsync not working” (in German) and found that awesome piece of customer advice that stands for itself.
yes, qnap was designed for working in the background , and which use different protocol as samaba, so it will be much slower than you transfer data to nas directly.
we had award this problem. developer are working on this, we will keep improve qsync function. sorry for your inconvenient.
Meaningless to say that I immediately deleted the “QSync (Beta)” client from my system.
After more than 10 years and after a thorough re-calculation of my family’s TCO on internet and server infrastructure, we came to the conclusion that it would be more economic to move the physical server and the associated leased line and IP subnet to a more modern cloud based infrastructure. (OK, I admit… It was actually way more spontaneous than it sounds… But I always wanted to say “TCO” in a blog post. 😉 )
Anyway – I had to
- find a cloud provider I trust
- relocate the server, services and data with as little downtime as possible
Luckily, my internet provider (iWay.ch) also offers virtual machines on a cloud based infrastructure entirely hosted in Switzerland – hello NSA – for a reasonable price. After going through all the contractual negotiations (i.e. click on ‘Agree’ on a web page) I got my cloud console login – like the one you get from Amazon.
I’ve set up an openSuSE 12.2 server from the provided template, ran a distro upgrade to 12.3 and my primary infrastructure was basically up-and-running within less than an hour.
A couple days before the actual migration, I did set the default TTL and refresh values for all my DNS zones to a very low value. This was to compensate the IP address change I had to undertake for my hosted domains. I did the change and pushed the updated zones out in the wild.
The first service I migrated was the DNS server. I “rsync” the relevant directories and then I went to the registrar of my domains and updated my name server IP address. The A records in the zone files still pointing to he old server, obviously. Shortly after I did the IP change, I began to see DNS requests to appear in my new server’s log files.
The next step was to replicate all the customer data (home directories, mail boxes and mysql data files) to the new server. I also chose to do this using rsync over ssh. After I set up the necessary sync jobs, I let it run over night to copy the initial set of data.
The next day I replicated the configuration settings of Apache, Postfix, dovecot and mysql to the new server the same way using rsync.
After some initial testing and tweaking on the new server, I ran the rsync jobs again and then I was finally able to make the switch on my DNS server by altering only 3 lines (A record for MX, A record for www and serial number). I shutdown the services on the old server and bounced the DNS on the new one and less than a minute later the HTTP requests and mail messages began to hit the new server.
At the end, I was a bit surprised how easy the migration went.
I realized that with only little planning and the right set of basic tools, you can get things done quickly – unlike some recent experiences I made at other places…