Kevin Boone

Comparing Dropbox, pCloud, and rsync.net for off-site storage for Linux users

Long-term data security is the elephant in the sitting room of the IT industry. We can still read Akkadian stone tablets from nearly four thousand years ago, but I can’t read documents I stored on DAT tape only thirty years ago. I have 70,000+ photos and five thousand hours of video, and that’s just from domestic activities. Of course, I have this stuff backed up on my home NAS, but what if there’s a fire? Or a burglary?

I imagine that the problem is even more acute for businesses, which have legal obligations to store documents for a period of time, quite apart from a need to protect their creative output. In this article, though, I focus on the domestic situation, where simplicity and low cost are primary factors.

I will consider three off-site backup and synchronization services that have some claim to be Linux-friendly: Dropbox, pCloud, and rsync.net. By ‘Linux-friendly’ I mean that they either provide specific software for Linux (Dropbox and pCloud), or use protocols that are widely used in the Linux world (rsync.net). I’m specifically not including Google Drive, because it offers no official support for Linux at all. There are third-party Linux tools that provide some measure of integration with Google Drive, and Linux users can still use its web interface. Nevertheless, I’m focusing on services that specifically target Linux – if only in a half-hearted way – rather than those that actively repudiate it.

The three services I describe in this article are ones that I have used extensively, over the last ten years or so. I have most experience with Dropbox so, if I seem particular hard on that service, it’s probably because I’ve had longer to get familiar with its faults.

Service overviews

Dropbox is the grand old man of consumer file sync services. It’s been around since 2008 and, for Windows users at least, it’s a stable, well-supported platform. The service has benefited from constant development, and is now quite sophisticated, offering a huge range of features beyond basic file sharing and backup. Whether any of those features are useful to a Linux user is debatable. Almost no experience is needed, to make effective use of the Dropbox service – even on Linux.

Dropbox provides a proprietary client which attempts to keep a single, local directory (typically $HOME/Dropbox) in sync with the server, and with other computers using the same account. There’s also a web interface, and a well-documented API for extensions, which is used by a range of 3rd-party applications. There’s no support for traditional file transfer protocols like FTP and, if you want to transfer files without syncing, you’ll need additional, 3rd-party tools (or you can write your own, as I did).

rsync.net is a much more focused service and, although it will work fine with platforms other than Linux, it’s really intended for people with significant Linux/Unix experience. rsync.net just provides a Unix filesystem, accessible over SSH. What you do with it is limited mostly by your ingenuity. You might choose to synchronize files with the server, as Dropbox does, or just upload and download using the command line. rsync.net also has a long history – it’s been around since 2001 although, in my view, it’s only in the last few years that it’s become (barely) affordable for small-scale users.

pCloud is a relatively new offering, introduced in 2013. It’s a similar kind of service to the one Dropbox offers, in that it uses a proprietary client. The client provides both synchronization and non-synchronized file transfers. Like Dropbox, there’s no support for traditional protocols like FTP. And, also like Dropbox, pCloud requires little experience to use, even on Linux. However, pCloud offers a more flexible synchronization process than Dropbox: you can select abitrary directories on the local machine to synchronize with any directories on the server.

In fact, pCloud exposes the entire shared storage as a directory, typically $HOME/pCloudDrive. This is in addition to its capabilities for synchronization, and has the benefit that you can use simple command-line tools to copy files to and from the server. So you don’t need any additional tools to transfer files without synchronizing them, which is an advantage over Dropbox, at least for Linux users.

Pricing

It’s almost impossible to compare the costs of these competing services effectively, because their pricing models are so different. So, in an attempt to make some kind of comparison, I’m looking at the cost of 2Tb of storage, paid annually, with no extra features, and a small number of concurrent users.

For this scenario, Dropbox offers the best value for money, at UK£96 per year. pCloud comes a close second, at UK£100. Trailing the pack, by a long distance, is rsync.net at US$288 (UK£220 at the current exchange rate).

If you need less that 2Tb of storage, however, then Dropbox is less appealing, because it offers nothing smaller. pCloud offers a minimum 500Gb for UK£50, while rsync.net offers its minimum of 800Gb for $103 (UK£78).

Whatever the storage size, rsync.net offers the least value for money for the basic service. However, there’s not a colossal difference between the prices of these services, and the prices change almost daily, according to the market and the current exchange rates. Moreover, all the services have useful optional features that increase the price. All have longer-term and lifetime pricing, but it’s hardly worth comparing these offerings, because their prices change so enormously, so frequently.

Both pCloud and Dropbox have a completely free tier, offering quite small storage (typically 5-10Gb). All the services have frequent special offers. For example, at one time Dropbox provided one year of 2Tb storage to everybody who bought a Samsung phone. At the time of writing, buying a one-year subscription to the Private Internet Access VPN gets you a free year of 500Gb pCloud. It’s worth watching out for these offers, because they make it easy and cheap to evaluate the services in realistic usage patterns. Sadly, at this time rsync.net has no free tier, nor even a free trial.

Linux compatibility

The most important point to note is that if you want an install-and-forget, background file synchronization method, then none of these services is satisfactory. rsync.net won’t be satisfactory because it simply isn’t designed to work that way. Dropbox and pCloud won’t be satisfactory because they just don’t work very well on Linux.

Note
Please note that I’m referring here specifically to unattended, background synchronization – there are other ways to use all these services, that work perfectly well. However, both pCloud and Dropbox are mostly aimed at providing background synchronization services, and the fact that they don’t work very well on Linux is a mark against both of them.

I feel I should also point out that the background synchronization works tolerably well with Dropbox for small amounts of synchronized data (much less than 10Gb). pCloud doesn’t work very well even with small amounts of data.

What goes wrong? Here are some things I’ve noticed.

My attempts to keep hundreds of gigabytes of data in sync using Dropbox were a complete failure. I found Dropbox often using 30%+ CPU even when it seemed to be idle, for long periods of time. pCloud couldn’t even manage 10Gb reliably.

It’s important to understand that background synchronization is a tricky problem, when multiple client computers are involved. One particularly nasty situation arises when several clients are editing the same file at the same time. Both Dropbox and pCloud keep copies of the affected file, with ‘conflicted’ in the filename. If you’re working on the same file from multiple computers, it’s not unusual to end up with many copies of the file on every computer, all with a version number and ‘conflicted’ appended. Working out which is the authoritative copy can be tricky.

This isn’t a problem that is specific pCloud or Dropbox – it’s a general problem of distributed file management. However, at the time of writing, pCloud’s implementation of conflict management is simply buggy. I’ve noticed that a file I’m editing will sometimes disappear completely, and be replaced with a new file with a ‘conflicted’ name, even when no other client is editing it. This is a particular problem for files that I save often. The pCloud application often emits error messages about files that could not be synchronized even when they have been. That’s not a huge problem in itself, but its hard to trust the error reporting from the pCloud application.

But what about non-synchronized file transfers? By this I mean files that are transferred to and from the server using specific administrative actions. Here all the services work fine except that, for Dropbox, you’ll have to find 3rd-party tools that use the Dropbox API to do the transfer – nothing is supplied. For rsync.net you can just use rsync, or any conventional file transfer tool. For pCloud you can just copy files to and from the pCloudDrive virtual directory. However, a plain rsync operation is simply much faster than any of the proprietary transfer methods.

rsync.net offers the best Linux compatibility of the three services, because it’s so simple. There’s no proprietary client – you’ll just be using tools that have existed in Linux for decades. In addition, the rsync.net technical staff actually understand Linux, which is a huge advantage over the competition. For both Dropbox and pCloud it’s hard to talk to anybody who knows anything at all about Linux, and it’s clear that Linux support is not a priority. For example, the pCloud Linux client produces error messages that refer to web pages which describe only Windows.

Web interface

Both Dropbox and pCloud offer a web interface for uploading and downloading files, which make these services useable on computers that don’t have the proprietary client software. rsync.net does not offer similar web features but, to be fair, it doesn’t require any proprietary software. rsync.net works with any computer that can use standard Linux/Unix file transfer tools.

rsync.net does have a web interface, but it’s generally for high-level administration: billing, managing snapshots, that kind of thing. So far as I can see, you can’t use it for managing files.

Support for FTP, etc.

rsync.net supports SFTP, and you can also run administrative and transfer operations directly over SSH. You can use graphical rsync and SFTP clients if you wish, or just command-line tools. None of the other services support traditional file transfer protocols.

Mobile device support

Dropbox and pCloud both offer apps for Android and iPhone. I’ve not used any of these extensively, so it’s hard for me to comment. The Dropbox Android app only supports selected file transfers, not background synchronization, so it’s of little more use on an Android handset than the web interface. I don’t know if the iPhone app is more useful.

To use rsync.net with a mobile device, you’ll need an app that supports rsync or SFTP and, again, you’ll need to select specific files and directories to upload and download. Obtaining compatible apps is not difficult and, because I’m a geek, I just run rsync from a terminal on my Android devices.

Since this is an article about Linux, not Android, I don’t want to go into too much more detail here. In any event, I’m not really in a position to, since I never found the mobile apps very useful, and don’t have much experience with them.

Security and encryption

All the services described in this article encrypt data on the wire, using methods that ought to suffice for non-military scenarios. But that’s only part of the problem – we also have to consider encryption ‘at rest’, that is, encryption of the data on the provider’s servers. So far as I know, only pCloud offers true end-to-end encryption, with the stored data only decryptable by the client. And this comes at substantial additional cost.

So far as I know, Dropbox offers no end-to-end encryption, so the confidentiality of your data turns on the integrity of the Dropbox staff. So far as I know, there’s nothing to suggest that they can’t be trusted, but this is an issue that users should be aware of.

As in most things, rsync.net leaves the encryption in the hands of the user. If you just rsync files to the server, then they will be stored on the server in exactly the same format as you send them, with or without your encryption. If, instead, you use a backup application like Borg, then you can apply encryption if you like. rsync.net offers the greatest flexibility in this regard, as in most others; but you need to have the skills to take advantage of it.

Teamwork and file sharing

Dropbox is the undisputed champion in this area (since I’m excluding Google Drive). You can share files with selected permissions with any Dropbox user, and these become available for background synchronization. You can even share with non-users, who can interact with the web console. In fact, Dropbox has a huge range of collaboration tools; I can’t really comment on how well they work for Linux users, since I’ve rarely used them.

pCloud also offers some collaboration tools, but they don’t seem to be as well developed as the Dropbox offering. Again, it’s not easy for me to comment, because I don’t often use these tools.

rsync.net offers nothing like this – it’s hard to see how it could, given its basic architecture as a remote filesystem.

File administration

Background file synchronization is intended to be administration-free: the client computers and the server end up storing the same files. Filesystem administration is therefore done on the clients.

Problems arise for both pCloud and Dropbox when using them for unsynchronized transfers, that is, for explicit file uploads and downloads. What do you do, for example, if you upload a huge bunch of files, accidentally including some types of file that you don’t want to store at all (temporary files, compiler output files…)? Fixing this situation is problematic on Dropbox, because you have to explore the files using the web interface, and select the unwanted ones for deletion manually.

It’s easier with pCloud, because the Linux client exposes the entire storage as a virtual directory. So you can use ordinary Linux commands to manage files (find, rm, grep, etc). But because these commands run on the client, and the files are stored remotely, these procedures can be painfully slow.

rsync.net allows you to run arbitrary shell commands (with some restrictions) directly on the server. So if I want to remove all the .o files from my source code directory, I can run find source -name *.o -exec rm {} \; on the server. I can run this command on the local virtual directory with pCloud, but it could take all day.

With rsync.net you can even mount the entire remote filesystem using sshfs, and then use it in the same way as pCloud’s virtual directory. But it’s much quicker to administer the server directly, and none of the other services provide a way to do this.

Data recovery and snapshots

All the services I’m considering here have tools for data recovery, that is, restoring accidental changes to the storage. These tools are presented in different ways but, essentially, they all amount to filesystem snapshots. All the services often some number of snapshots free of charge, but long-lasting snapshots are usually typical of a more premium service. rsync.net is a bit different in this regard – you can have as many snapshots as you like, and keep them as long as you like, but the storage counts against your overall quota. Since only differences are stored, this might not amount to a huge amount of storage.

With Dropbox and pCloud, changes made by data recovery tools are rolled out to the synchronized storage on clients. So you might find that files appear on the clients, or disappear. rsync.net just stores snapshots in a hidden directory on the main filesystem.

Summary

pCloud and Dropbox are, to some extent, directly comparable, because they both specialize in background, unattended file synchronization. At this time, I’ve found the Dropbox client to work better under Linux than the pCloud one. However, the pCloud client has the advantage that it creates a virtual directory that maps the entire server, so you can use the same software for both background synchronization and explicit upload/download operations. For me, this advantage isn’t sufficient to overcome the poor reliability of the pCloud client on Linux, nor is the slightly lower cost of pCloud. Arguably, if I needed to use end-to-end encryption, and didn’t mind the slight additional cost, that might make me favour pCloud. Still, the unreliability of the client simply rules it out for me, regardless of cost or features. To be fair, the pCloud Linux client has improved quite a lot since I first tried it about five years ago. It’s almost useable now and, since there are regular updates, I remain optimistic about it.

The Dropbox client is just about reliable on Linux, for small amounts of data (< 10Gb). For data I need to store, but not synchronize, I wrote my own command-line client. The Dropbox proprietary client uses extended file attributes as part of its operation, and only supports ext4 filesystems – that will be a limitation for many users.

In the end I found that I was mostly using Dropbox for explicit upload and download operations – I didn’t really use the background synchronization, because I just had too much data for the client to cope with. If I only had 10Gb of data then I imagine Dropbox would work fine – but then I wouldn’t want to pay for 2Tb. I will reconsider if Dropbox starts to offer a per-Gb pricing model, as rsync.net does.

It’s also worth bearing in mind that, for straightforward file uploads and downloads – particularly uploads – rsync.net is much, much faster than Dropbox. It’s at least ten times faster, but probably more. I guess partly this is because simple protocols like rsync and SFTP are just faster than the proprietary ones. But also I think that Dropbox deliberately throttles some kinds of transfer.

For a Linux user, rsync.net offers much more flexibility that any of the alternatives I’ve tried. If you want transparent synchronization you can have it – but you have to implement it yourself, using scripts or similar. You’ll probably need more self-discipline to use rsync.net than the other offerings, because it doesn’t hold your hand at all.

In the end, there is no clear winner for me. All these services have advantages and disadvantages. pCloud would be a definite winner, if only its Linux client were more reliable. At present, I’m using rsync.net, although it offers the least value for money, mostly because it’s so fast. Still, it’s galling that rsync.net offers the least storage, and fewest features, for my money. I guess that’s because it’s less a mass-market offering than the competition. Still, it’s nice to use a service for which Linux users are not second-class customers.

The other great advantage of rsync.net for me – and this probably won’t apply to everybody – is that I interact with it exactly as I do with my home NAS. I already have most of the tools I need, to use it effectively.