Rick-Ross.com

Over the past several days, I have written about a relatively new comer to the Linux hosting world, 6Sync. They offer virtual Linux servers that are fast and can scale, adding memory, disk space and bandwidth as you needs grow. I have been extremely impressed with their support team, who has consistently answered my questions in a very quick manner, usually within minutes of creating the support ticket.

Setting up a new server is very easy, and their backup strategy will protect you from unexpected situations. And when you mistakenly overwrite a file, restoring from a previous backup could potentially save you a lot of time.

6Sync is not a solution for those who are inexperienced with configuring and setting up a Linux server – 6sync is for people who enjoy configuring servers from the command prompt. For developers and system administrators looking for a solid hosting platform, 6Sync is a young startup that is moving to dominate the virtual server space. As with any startup, they have growing pains, but even with a few minor issues I encountered along the way, they were ready, willing and able to quickly help me resolve them.

Would I switch to 6Sync? That is a great question. Here’s some background before I answer it.

My historical practice for backing up data on a hosted Linux server has been to use a snapshot approach. That is, a backing up the data is performed by making complete image of the operating system and data.

For certain applications, like a Linux file server shared by many people, I see the value of being able to restore specific files from previous backups. When a person accidently overwrites a version of a file and needs to restore an older version, having the ability to recover a single file is done much more effectively and efficiently with a file based backup.

In my situation, I have a Linux server that hosts a number of websites, so I am missing a narrative around the value of backing up individual files that don’t change that frequently. (The database(s) do change frequently, however). For me, I prefer the convenience of taking an ad-hoc snapshot just before performing operating system updates. That way, if something goes wrong, I can quickly restore my server the way it was just moments before.

My answer to the question would I switch to 6Sync is unfortunately no (at this time) because of my current practices of backing up using snapshots. (Another concern of mine would be the time, effort and coordination required to move to a new server). That being said, I am open to hear what others have to say so I can learn about new and more effective practices for managing Linux servers.

Have any thoughts or insights? Please leave a comment, or two.

Yesterday I wrote about 6Sync’s backup strategy. This post will report on my experiences with backing up and restoring data.

The first step in protecting your server is to enable the backup feature which I accomplished by selecting 20 GB backup storage. Once enabled, I selected my server that I wanted to protect and a backup frequency of 24 hours. After I made choices, I received an email that contained 8 or so steps necessary to configure the R1Soft backup agent.

What was confusing to me is that in Biscuit, 6Sync’s management console, even after enabling backups, it appeared that they were not enabled.
Mario indicated that they had other people who had similar comments and that they will be addressing this usability issue in the near future.

After waiting for the first backup to complete, I wanted to see how I would restore files. This is accomplished by launching the R1Soft web interface and using the supplied credentials that are displayed within Biscuit.

Initially, I was confused with the R1Soft web interface because it appeared that something wasn’t right. Any folder I clicked on did not have any files within them. And yet, the size of the completed backup indicated to me that it did contain files.

So I entered a ticket in 6Sync’s system and they sent back a screenshot of my backup showing files that I didn’t see. I thought that was strange and so tried a different browser. Sure enough, I was able to see the files with Firefox but not with Chrome. I was thankful that the issue was a browser incompatibility issue which will likely be addressed in a future release.

Restoring one or more files is pretty straightforward, you select the files you wish to restore, and determine where you want to restore the files. You can overwrite the existing files, restore to an alternative location on the same server, or restore to another server.

The backups ran successfully for a couple of nights. Today when I checked them, however, I noticed a failure within Biscuit. Looking at the logs, R1Soft was unable to talk to my server. I contacted support again and through a couple of exchanges quickly determined that when I installed new software on the server caused a conflict in the kernel module.

Solving this issue was simple as running r1soft-cki which reinstalled the kernel module and then starting the backup agent. Support indicated that they are in the process of creating a knowledgebase to help other people who encounter this problem in the future. A best practice to avoid this situation in the future is to run the r1soft-cki anytime you upgrade the kernel, which may happen automatically if you use the “yum update” command.

While there are a few rough edges that need a little sanding, 6Sysnc’s backup and restore functionality works pretty well and will certainly protect your data. It may take you some time to get comfortable with the R1Soft Web Interface as it is overwhelming at first glance, but once you overcome the busyness, you’ll appreciate the capabilities.

I’ll wrap up my series on 6Sync tomorrow with some additional thoughts.

Updated to include clarification on when to run r1soft-cki based on Mario’s comments and to complete a missing sentence.