- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Crash[plan and multiple NASes. Best strategy?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Crash[plan and multiple NASes. Best strategy?
OK, I have multiple ReadyNASes. All are legacy, but some are on OS4.2.x and some on 6.x. I plan to move them all to 6.x once I'm convinced the bugs are worked out. The older Pro models have upgraded processors and memory (E6700 & 2 or 4GB) while the Ultra4 and Ultra4Plus have standard processors and 2GB.
I'm looking at Crashplan. Since everything for a NAS us "unsupported", I'm looking at the best way to utilize it. I see a few ways to accomlish it and would like comments on the benefits.and pitfalls of each. They all depend on Crashplan continuing to be usable with the unsupported modes of headless operation on the NAS or utilizing Windows mapped drives
Plan A: Install Crashplan on all NASes and computers. I'm sure this gives me the most control. I don't think I want to deal with the differences in installations between OS's. so upgrade of all to 6.x is the first step, but I'm not sure I'm rewady for that. Major disadvantage I see is that (according to Crashplan site), a headless configuration does not auto-update and there is no way to trigger it. Updating requires uninstalling and re-installing, including re-doing all of he "hacks". Not being the biggest 'Nix guru, that's a lot of work if updates come quickly. Another disadvantage is each NAS counts toward the 10 computers in a family plan, though I won't currently exceed that. If I want to use remote access to administer Crashplan, I need to port forward externally, have a PC with remote access also left on, or implement a VPN. Externally forwarding Crashplan ports seems a bad idea, even with atrong passwords.
Plan B: Convert a currently retired PC into a "Crashplan server". It's pretty much of the same caliber as the NASes: Win 7 (10 if I upgrade the video) Core2 duo processor and 4GB of RAM. I can map //nasIP/c on the OS4.2.x NASes and //nasIP/data on the OS6.x machines as mapped dives and then access them via that computer. This has the advantage that all updates will happen automatically. Disadvantages are that the computer has to remain on and and all crashplan traffic goes through it. With bandwidth to my ISP probably being the biggest bottlenext, I'm not sure the latter is really an issue. Or is it?
Plan C. Kinda like plan 2, but use a NAS as the "Crashplan server". I know Linux can mount external volumes, and I believe the ReadyNAS can utilize that, though I have not tried it. Crashplan site implies that using mounted server shares in Linux is a supported feature. I'd probably use the Ultra4Plus for that, since it's current backup function would become moot with Crashplan. It still means I need to keep a NAS installation up to date, but only one. And I can choose when to move from OS4.2.x to 6.x. It's also one more machine on all the time (it currently comes on only for backup job) and if I want to use remote access to administer it,it has the same issues as A.All traffic now goes through an Ultra4Plus -- is it up to the task?
So, have I missed any pitfalls or benefits that might sway me? Is anyone using a plan similar to any of these, or something I haven't considered?
I'm leaning toward starting with Plan B, and I coould migrate all or part to Plan A or C. With only a 30 day trial period, I want to try what makes the most sense first.
One somewhat unrelated question: If "a friend" (not enrolled in a paying plan) uses my NAS as a backup, using any of the scenarios above to access it, does Crashplan recognize that that is backup data and disallow it's archival in the Crashplan cloud even if the folder containing the backup is marked for cloud archival?
And, lastly, is there another service that I should be considering instead that will work with one or more of the schemes above? Most, I believe, won't work with Plan B, as they do not allow backup of maped server shares.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Crash[plan and multiple NASes. Best strategy?
@Sandshark wrote:
One somewhat unrelated question: If "a friend" (not enrolled in a paying plan) uses my NAS as a backup, using any of the scenarios above to access it, does Crashplan recognize that that is backup data and disallow it's archival in the Crashplan cloud even if the folder containing the backup is marked for cloud archival?
Yes. At least it does that in my setup (which is similar to your plan "C" but not mounting any PC drives on the NAS).
@Sandshark wrote:
Plan A: Install Crashplan on all NASes and computers. I'm sure this gives me the most control. I don't think I want to deal with the differences in installations between OS's. so upgrade of all to 6.x is the first step, but I'm not sure I'm rewady for that. Major disadvantage I see is that (according to Crashplan site), a headless configuration does not auto-update and there is no way to trigger it. Updating requires uninstalling and re-installing, including re-doing all of he "hacks". Not being the biggest 'Nix guru, that's a lot of work if updates come quickly. Another disadvantage is each NAS counts toward the 10 computers in a family plan, though I won't currently exceed that. If I want to use remote access to administer Crashplan, I need to port forward externally, have a PC with remote access also left on, or implement a VPN. Externally forwarding Crashplan ports seems a bad idea, even with atrong passwords.
First of all, the headless configuration does auto-update - and glitches in that auto-update has caused some issues for ReadyNAS users over the past six months. So far, the PC clients have updated after the linux ones. And Crashplan isn't very fast about posting the most recent PC client version on their website. Occasionally that results in incompatibility with the crashplan client and the headless server. However, I haven't found that to be a big deal - looking at the tail of the crashplan logs on the NAS gives essentially the same information.
I haven't needed to forward crashplan ports in the router - I do use remote desktop access when away from home (though I have more recently set up a VPN).
Switching between normal local Crashplan Client/Server and using the PC client to control the NAS is a bit of a nuisance. It requires manually editing a PC file. Sometimes after a server upgrade, you also need to examine /var/lib/crashplan/.ui_info on the NAS and copy an authentication code into ui_info on the PC.
BTW, there is a mobile app - it doesn't give you much management control, but you can see the status.
@Sandshark wrote:
Plan B: Convert a currently retired PC into a "Crashplan server". ... Disadvantages are that the computer has to remain on and and all crashplan traffic goes through it. With bandwidth to my ISP probably being the biggest bottlenext, I'm not sure the latter is really an issue. Or is it?
I haven't done this, so I haven't any real data on the performance trade-off. The PC client is what scans the files to determine what needs to be backed up, and also is what does the deduplication. So there would a fair amount of local I/O over your gigabit network.
On the other hand, the linux version of crashplan has limited memory (it has to use the 32 bit VM) and de-duplication is a memory hog. I maxed my pro6 memory (now 8 GB), and also maxed Crashplan's VM (to ~3700 MB). If I run out of memory again, the only practical recourse is to switch to plan B.
So if I were doing my own setup over, I'd probably start with Plan B, and see if the performance was adequate. In addition to the above considerations:
-Plan B is a bit easier to do in the more recent crashplan versions - you install it as a "per user" application, map the drive letters, and add them to the Crashplan list. Then you are done.
-With a variation of your Plan C, my Crashplan backup service has been disrupted 3 times in the last 6-7 months. First I ran out of memory, and spent several weeks compacting the CrashPlan central datastore (after setting a 3-month retention limit there). Then a crashplan auto-update failed because it assumed Java 7 - and it failed in a way that filled my OS partition. After that, a second update required a new libc. The new constraints (Java 7 and the library version) were not announced ahead of time.
The good news here is that (despite "not supporting headless clients") CrashPlan support did help me resolve my issues. But these issues would likely not have arisen at all if I had gone with plan B. Note that I had no issues before this year (and have been using Crashplan since 2012).
-A third consideration: I have been wondering generally about using a PC server instead of add-ons on the NAS anyway.
@Sandshark wrote:
Plan C. Kinda like plan 2, but use a NAS as the "Crashplan server". I know Linux can mount external volumes, and I believe the ReadyNAS can utilize that, though I have not tried it.
I don't think I'd mount the PC volumes on the NAS - because of the memory limitation above. Also there are files on the PC that are hard to back up (the user profiles), and a dedicated PC backup program generally handles those better.
What I do is create incremental image backups on the NAS from the PCs (using Acronis TrueImage). Then CrashPlan backs these up to CrashPlan Central. De-duplication helps quite a bit on the Crashplan step.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Crashplan and multiple NASes. Best strategy?
Hey, Stephen, thanks for your comments. You've made me think my Plan B choice is at least the place to start, as I suspected. I've got a lot of data, so I suspect I'll have similar issues with de-duping and such, which certainly makes using the Ultra4Plus as the "server" a bad idea,. If I need to, I can upgrade my PC "server" -- it will accept a Quad processor and more memory a lot easier than the NASes.
I've seen some issues posted when Crashplan updates their software on the NAS and really wanted to avoid all that -- especially on multiple NASes. I could write a batch file for moving between NASes and local control with the Windows front end, but that's just for routine swapping. Changes due to updates would be manual. And if the updates are automatic, unlike what I thought, then I can't even choose when to do it. I can do without all that.
I didn't plan to mount any PC drives on the NAS in Plan C, anyway, but that doesn't change things. I don't expect to do away with my existing PC image backup plan, either, but would now have them doubly backed up -- the NAS and Crashplan cloud. My current overall backup plan is multiple NASes in the same location. The files on the primary NASes and the PC images are backed up to other NASes, which does not protect me from theft, fire, hurricane, etc. This would do that, plus free up some NAS space by eliminating some local backups while adding some additional redundancy (cloud backup of PC images). And with space freed, it makes my migration to OS6.x on all of them easier.
I have some family members who backup remotel;y to my NASes, too. That was why I asked about backing up others' backups -- I could shift them from ReadyNAS remote/ReadtCloud to Crashplan free. But I'm not surprised that it's disabled -- it would make my kind of plan a way around the fees if you don't mind there being a middleman.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Crashplan and multiple NASes. Best strategy?
@Sandshark wrote:
I have some family members who backup remotel;y to my NASes, too. That was why I asked about backing up others' backups -- I could shift them from ReadyNAS remote/ReadtCloud to Crashplan free. But I'm not surprised that it's disabled -- it would make my kind of plan a way around the fees if you don't mind there being a middleman.
They can do "friend" backups to your NAS over the internet (via the PC if you are using plan B). But their backup files won't be backed up at Crashplan Central. Also they are gibberish to you, so you can't access their data.