Quite a bit has happened since I reported in September. Seafile 2.0 was released, and that release just happened to coincide with a hardware failure. That was actually pretty convenient for me, since I wanted to rebuild my libraries with Seafile 2.0’s improved encryption.

Seafile server bandwidth usage

I was really hoping to have at least a couple months’ worth of good bandwidth reports by now. Unfortunately, I’ve had reason to upload large amounts of data every single month since I started using Seafile. One month my data was uploaded, then Chris’s data was uploaded the next month. I had a hardware failure the month after, and I had to upload my data to the new Seafile 2.0 server. We didn’t get around to uploading Chris’s data again until last month.

We’re not quite two weeks into December yet, but I haven’t had a reason to upload any libraries from scratch yet. Chris and I have only used about 1.5 GB’s worth of bandwidth so far this month. We’ll probably finish the month out with well under 4 GB of bandwidth use. I’ll come back and replace this paragraph in a few weeks when I know the final bandwidth total.

I’m very happy with that. It is barely a blip on the radar. I could almost fit numbers like these into our tiny, inexpensive mobile data plans.

Update: I’m counting down the final hours of 2013 and updating the Seafile server’s bandwidth screenshot image. It looks like we came in at 2.74 GB of bandwidth usage for the month of December. I will be quite pleased if most months end up looking like this!

Seafile server disk usage

I have a total of 11 GB of data in 69,022 files spread across twelve separate libraries. The most files that I have in a single library are 22,347. These libraries are all kept in sync on both my desktop and laptop.

Chris has a single 31 GB library containing 14,596 files, and she has only one computer.

All the libraries are configured to expire deleted files after 90 days.

Seafile performance

When I first started using Seafile, I was only using a single computer with a fast solid-state drive. I had no performance issues at all. I could boot my computer up, and Seafile would finish checking my local libraries for changes before I could even think to look.

When I bought my new workstation, I had to put a traditional 7200 RPM hard drive back in my laptop. The laptop is now excruciatingly slow for two or three minutes after booting up.

My start-up scripts are pretty aggressive. They simultaneously start up all the long running applications that I use all day long. Things like Emacs, Chrome with a bunch of tabs, Pidgin, Thunderbird, and LibreOffice. These would all be ready to use in just a few seconds with the solid-state drive. They take almost a full minute to get up and running on the old, slow, spinning disk.

Now it takes Seafile almost three minutes to scan my libraries. That is certainly not a ridiculous amount of time to check nearly 70,000 files. It isn’t want I’m used to, though.

The server-side requirements are also extremely light. The virtual server that I’m running Seafile on is configured with only 256 MB of RAM and 96 MB of swap space, and half of that is being used as disk cache. Running in such a small virtual machine hasn’t been a problem at all.

Seafile sync speed

I was pleasantly surprised a few weeks ago. I had the same file open on my laptop and desktop. I made some edits on my desktop and walked away. When I got back, I sat down at my laptop and was surprised to see my changes staring back at me!

By default, Emacs prompts you when it notices a file has changed on disk. I had completely forgotten that I had configured it to automatically reload when a file changes on disk. I was bouncing back and forth between computers as though I were accessing a share on a file server!

Of course, it isn’t quite as fast as a file server. It takes about 20 to 30 seconds for the change to be detected, uploaded to the server, and downloaded to the other computer. That is definitely fast enough for me, and it is very nice to be able to pick up working right where I left off, even if I forget to commit my work in Git before I walk away.

Testing my Seafile backups

I’ve been procrastinating. I back up my Seafile server every day, but I haven’t gotten around to restoring any of those backups to a test server. Since an untested backup may not be a backup at all, I figured it was time to stop procrastinating.

Testing the backups was really simple. Each of my daily backups are stored in btrfs snapshots. All I had to do was chroot into them one at a time, restore the database, and fire up the Seafile service. All I had to do was follow along with the instructions in the Seafile backup and restore documentation.

1
2
3
4
5
6
7
8
9
10

wonko@backup1:~$ sudo btrfs subvolume list /mnt/vz-rsync/
ID 439 gen 352 top level 256 path .snapshot/rsync_2013-12-03_23:34:16
ID 442 gen 357 top level 256 path .snapshot/rsync_2013-12-04_14:57:11
ID 448 gen 371 top level 256 path .snapshot/rsync_2013-12-05_16:03:00
ID 480 gen 444 top level 256 path .snapshot/rsync_2013-12-06_15:41:10
ID 509 gen 426 top level 256 path .snapshot/rsync_2013-12-07_07:18:05
ID 515 gen 457 top level 256 path .snapshot/rsync_2013-12-08_01:39:49
ID 520 gen 462 top level 256 path .snapshot/rsync_2013-12-09_01:12:41
ID 526 gen 468 top level 256 path .snapshot/rsync_2013-12-10_01:17:34
wonko@backup1:~$

The first one took the longest to test. Seafile or Nginx didn’t want to start up until I mounted the proc file system in the chroot. It was easy to test a few random days once I got that problem squared away.

A convenient bonus

Cloud storage software like Seafile is a great way to help protect yourself from ransomware like CryptoLocker. If I notice that my library has been corrupted, I can just click a few buttons and restore the entire library to a previous state. I can go back to yesterday, or last week, or as far as I need to go.

I’m using Linux, so I’m not a target of CryptoLocker. Ransomware is some pretty insidious stuff, though, and storing or backing up your data in the cloud is a good way to keep yourself safe.

You don’t have to host your own cloud backups to get a good deal. I’ve heard good things about Backblaze, and I’m looking for an excuse to build one of their awesome, big, red storage servers. They don’t seem to support Linux, though. I’ve also heard good things about Crashplan, and they do support Linux.

Seafile’s own service, Seacloud, has pretty good pricing on their “team” packages. You can sign up for a single account, create libraries for multiple users, and let everyone share the same storage quota. That seems like a pretty good value to me.

There’s a lot of overlap between “cloud storage” and “cloud backup.” “Cloud storage” is generally aimed towards syncing your data between multiple machines, while “cloud backup” is geared more towards moving your data from one computer up to the Internet. If you just want to keep your data safe, then one of the various backup services is probably a better value for you.

The verdict

I had a lot of cloud storage options to choose from six months ago, and I definitely made the right choice. Seafile has just the right combination of encryption, performance, and storage efficiency to meet my needs, and it has made the process of using multiple computers a much more pleasant experience.

There are some interesting features due out in the next couple of months that are listed in the Seafile 2.x Roadmap. I’m looking forward to the improved syncing speed. Improved performance will most likely let me squeeze a little of extra life out of my laptop’s new battery.