#Crashplan slow windows

UAC on Windows will cause some problems, but CrashPlan is writing to the Program Data folder perfectly fine, so moving the flags there should work. Missing a week (assuming weekly status reports) is far preferable to missing 4 and a half months.Īlternatively, where it’s just a flag in a command line, rewrite the flag automatically. I could have had the problem resolved quickly if I had been told about it. I’d guess that 99% of the clients will probably never hi, say, 1.5TB of files.īut for the 1% that do, notify them instead of failing silently. It seems to be based on the size of the files that people are backing up, not the number of files, which to me makes me think that their block detection/hashing algorithm is what’s chewing up memory. Quick fix: Catch the outofmemory errors, and tell the user or resolve it automatically.it’s vaguely amusing at how an easily fixed root cause (Crashplan running out of RAM to presumably stash file metadata) coupled with a over-simplified status report and ineffective monitoring created a much more serious effect. I’m just glad I found this before any data loss did occur, because I’ve been lax in backing up to an alternate location. Now, none of this is truly serious for the simple fact that I haven’t lost any data, and I’m thankful for that. In my case, that’s an oops since it covered up a serious problem. I imagine people saw the two times and were confused, so CrashPlan merged the two times. Ironically, the backup status report sample that CrashPlan has in their docs (dated June 15th 2009) fixes this problem. My “Last backup” times apparently meant “Last connected”. Which means one thing: backups weren’t succeeding, but I was told everything was OK. And not just because I hadn’t been taking photos that much. My list of picture folders on the CrashPlan web interfaceĪnd promptly had a mini-freak out. This is a screenshot of the most recent CrashPlan report that I got sent: Backups have at least one edge case where they’ll fail silently. So that means CrashPlan ran out of memory and restarted at least 260 thousand times without me knowing. I actually thought ls crashed.)Įach and every file seems to have been created when the CrashPlan Engine restarts. (I’m not kidding, I started a new SSH session to kill ls the first time I tried to list the directory because it was Taking. In the configuration directory, I found a bunch of restart.log files while hunting for the file which defined the memory limits. I raised the memory limit to 1.5GB, and Java’s only using 932MB, so there’s some headroom for growth if necessary. OutOfMemoryError occurred.RESTARTING! message=OutOfMemoryError in BackupQueue!īecause the file set changes very irregularly, once it starts crashing, it’ll continue to crash until you intervene and manually raise the memory limit. It seems that beyond a certain number of files, Java hits the hard memory limit and dies: I’d periodically go in via VNC and check up, and the desktop interface reported everything was just fine.Įxcept it wasn’t. I quite enjoyed this because my media server is headless, so set-it-up-and-forget-it backups were awesome. I’ve been getting weekly reports on my backups since I installed it. However, the hard limit led me to another problem: 2. I’m not the only guy who’s noticed this: One guy has it hitting 1.5GB of RAM. It’d regularly hit the max, but it didn’t seem to have problems, so I chalked it up to the use of Java and left it at that.

I have it running on my media server, which has been specced with 1GB of RAM. This is a hard limit imposed on the Java VM when it runs. Ridiculously so.īy default it’s setup to use a maximum of 256MB of RAM. I went looking for what could cause it to start & stop with such regularly, and found the first problem: 1. Spoiler: It was dying and being restarted by a watchdog of some sort.