I'd been lusting after Carbonite and even recommended it to my daughter and her husband. He became a big fan with hundreds of gigabytes.
But I had been limited by the upload speeds of my DSL connection. Well, DSL is no longer part of my life!
So I revisited Carbonite. In my research I came across several competitors: Backblaze, CrashPlan, SpiderOak, etc.
CrashPlan stood out to me as it allows you to provide your own offsite backup at no cost and without the long initial upload phase. And it's TNO (Trust No One). Their instructions are here. I did that. It works perfectly.
I seeded my backup folder onto a 500GB USB drive. 200+ GB took just over 6 hours. Then I took it to my mother's. I plugged it into a backpanel USB port so she wouldn't see it and unplug it!
Here're screenshots of my CrashPlan configuration and history log.
On the "Restore" screen you can see that the file XMASNAMES2013.doc has several versions in the backup set. The line near the bottom has clickable links where you can specify which version to restore, where to restore to, and whether to overwrite or not.
On the "Settings / Security" screen you can specify your own encryption key.
On the "History" screen you can see that it is backing up every 15 minutes during the trial period.
You can see an interesting impact on my bandwidth. On 01/01/14 I began downloading 2 Windows 7 ISO files. They didn't complete until early morning on 01/02/14. Each was about 3GB. Not thinking I put them on my desktop which is included in my CrashPlan backup set. Subsequently CrashPlan uploaded those ISO files to my offsite system.
CrashPlan worked great for a couple of days and then started complaining that it couldn't reach the remote system. I hadn't changed anything.
After several fruitless exchanges with CrashPlan support I turned to Google and found this thread on DSLReports.com. I began a dialog with one of the participants and he showed me what I needed to do.
All that was necessary was to open port 4242 on each of the routers and forward them to the appropriate system. A day or so after doing that and rebooting both systems CrashPlan was back working fine. Longer term I'm going to move the port 4242 activity to another less well known port. There's a setting in CrashPlan to do that.
Here are a couple of days of logs from both ends.
SERVER is the system being backed up and BYHALIA is the receiving system. While they are mutual backup targets of each other I don't have anything specified on BYHALIA to backup. (I have the user data on the BYHALIA system residing inside the Dropbox folder.)
I don't have CrashPlan's bandwidth throttled (which is possible) but the BYHALIA system's bandwidth is only 3Mbps.
It's also interesting to observe how CrashPlan minimizes the data transferred. On 01/30/14 at 12:12 AM it needed to backup 1 file of 260.70KB yet the data transferred was only 1KB. This is probably too much of a reduction for compression so CrashPlan must either be doing deduplication or block level backups.
From these logs it is apparent that CrashPlan only backs up once a day to remote folders. The early more frequent backup is when I finally got the port open between the two systems.
Tivoli is running fine so I see no need to abandon it. I may look at using CrashPlan's cloud offering to make some of my data available on my mobile devices.
Let's go through some scenarios.
Scenario 1: The USB hard drive at my mother's crashes.
I buy another USB drive and re-seed my backup folder. Then I take the new USB drive to my mother's and attach it.
Scenario 2: The computer at my house disappears.
I acquire a new PC and restore my system image backup (not from CrashPlan). Then I go to my mother's and get the USB drive and take it home. I attach that drive and the associated CrashPlan folder to my new PC and restore everything.
This is all in addition to my Tivoli backups.
Belt, suspenders, and raincoat.
No comments:
Post a Comment