Advertisement

CrashPlan stopped backing up (solved)

Home Forums CrashPlan on Synology DiskStation NAS CrashPlan stopped backing up (solved)

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #197
    an
    an
    Keymaster

    Hi,

    Just wanted to let you know of this particular issue I faced and that apparently has been solved.

    So like many of you I found my CrashPlan backup with the broken upgrade issues, and after repairing the upgrade CrashPlan wouldn’t backup any new files.

    Looking into CrashPlan’s logs there were two distinct behaviors:

    1. CrashPlan crashing because of “OutOfMemoryError” issues; rare but they were there. Very likely due to memory handling bugs on these last versions and not the actual available memory;
    2. File indexing and synchronizing random restart after indefinite amount of time, not related to the memory issue

    Regarding the memory issues, I could see that there wasn’t actually an issue, this was more like a bug. On one hand, free memory was available for use just before:

    [10.30.15 12:12:10.242 INFO BQTodoWkr-42 om.code42.utils.SystemProperties] == MEMORY End of backup; maxMemory=1600MB, totalMemory=1436.80MB, freeMemory=770.10MB, usedMemory=666.60MB
    [10.30.15 12:14:55.776 ERROR ub-BackupMgr .service.backup.BackupController] OutOfMemoryError occurred...RESTARTING! message=OutOfMemoryError in BackupQueue! 

    On the other hand, I knew from past versions (my backup hadn’t increased) that the amount of RAM I have available is enough for CrashPlan to run (2Gb), because it ran nicely for months before the last upgrades broke it.

    That said, I made a lot of tests, as uninstalling and reinstalling, erasing the local cache, reducing the number of Backup Sets just to see if that would make it kickstart, but it didn’t.

    After contacting CrashPlan support (which were actually very supportive) I ended up solving it after one last trial, where I forced the backup to “Compact” using the GUI. I can’t tell if this was what solved it, and the whole process took around 20 hours, but it is now working just fine.

    Hope this serves to help someone else!

    ps:
    By the way, CrashPlan support mentioned on different occasions:

    I will say that our engineering teams are aware and working to improve the update process for CrashPlan in attempts to prevent further upgrade from running into complications.

    Additionally, we have added additional security protocols regarding how source and destinations systems authorize prior to establishing a backup connection. These changes have also caused complications with some headless users.

    The last one I would read it to be related to the .ui_info tokens, but it could something else as well.

    #222

    Grant Nakamura
    Participant

    Not to be obtuse, but I guess I can’t deny the obvious!!!

    How exactly do you compact the backup set(s)?

    Advertisement
    #225
    an
    an
    Keymaster

    Not to be obtuse, but I guess I can’t deny the obvious!!!

    How exactly do you compact the backup set(s)?

     

    Not obvious at all, don’t worry!

    So go to Destinations > Cloud > CrashPlan Central

    You’ll see a “Compact” button at the right side of the “Space Used” line.

     

    CrashPlan Destination compact button

     

    #231

    Grant Nakamura
    Participant

    Got it! Thanks, I hope it fixes the constant stopping/starting.

    #234
    an
    an
    Keymaster

    No worries, I hope it helps. Just make sure you’re not having a Java Heap Memory issue, those are more common with the engine being restarting all the time.

    #236

    Grant Nakamura
    Participant

    When I press the Compact button it changes color, but otherwise no indication that it did anything.

    I had increased my heap size to 2048M just prior to registering on this forum. It had been 1500M+.

    It still seems to be restarting…

     

    #237
    an
    an
    Keymaster

    When I press the Compact button it changes color, but otherwise no indication that it did anything. I had increased my heap size to 2048M just prior to registering on this forum. It had been 1500M+. It still seems to be restarting…

     

    If you only have 2Gb of RAM I would guess it’s best not to set it to the maximum value, just so that the system doesn’t crank up.  I use 1.900Mb for a ~1.5Tb backup data set, which is fine.

     

    As for your issue; in my case I went through several different steps on these last few weeks trying to get it running back again, so it’s hard to pinpoint if it was just one thing that did the trick.

    But if you ask for my opinion, I would first check the logs (service.log.0) for restarting signs and see if there’s something going on. To leave out the Java heap size, search first for memory issues (look for “outOfMemoryError” and for “Memory”; with this last one you’ll see CrashPlan’s memory usage as it goes along). In my case I found a few OutOfMemoryError issues but with available memory just before, so it had to be something else.

     

    To look into the logs you  may want to read through this:

    http://crashplan.setepontos.com/checking-the-logs-for-crashplan-directly-on-your-mac/

     

    But the first major thing you should try is to clear the local cache. It will take hours to rebuild, but if after that CrashPlan will start series of different process stages, like “indexing”, “synchronizing file information, “synchronizing block information”, then it will be on the right track, I guess.

     

    For clearing out the cache consider the instructions from Code42:

     

    code42.com: CLEARING YOUR CACHE FOR QUICK FIXES

     

    #240
    an
    an
    Keymaster

    But to comment on the fact the Compact button didn’t do anything: I didn’t see any immediate response as well, but in the middle of the process it did pass through  a “compacting” stage.

    #243

    Grant Nakamura
    Participant

    Thanks for all the advice and info.

    I was wondering about an easier way to check the logs without

    I have 3GB installed, so 2048M shouldn’t be too bad. If I notice that it’s affecting other processes, then I will go back to 1500M+ I had before, but I’m at about 48% memory utilization on the Resource Monitor right now.

    I uninstalled and reinstalled the latest from patters. It’s in the Synchronizing block information stage right now.

     

    BTW, thanks for setting up this forum. It is way better than patters blog software and the endless comment stream!!!

     

    #244
    an
    an
    Keymaster

    Thanks for all the advice and info. I was wondering about an easier way to check the logs without

    I have 3GB installed, so 2048M shouldn’t be too bad. If I notice that it’s affecting other processes, then I will go back to 1500M+ I had before, but I’m at about 48% memory utilization on the Resource Monitor right now. I uninstalled and reinstalled the latest from patters. It’s in the Synchronizing block information stage right now.

    2Gb out of 3Gb is more than enough.

    I found that the DSM’s Resource Monitor is not a good tool for getting accurate information. Using the terminal you might get process usage, but in the end I found that the logs have this information well readable.  In any case the logs could help you identify any specific issue that you might find odd.

    If that doesn’t work and if you haven’t already this time, don’t forget to try to erase the cache on the next trial! Uninstalling/reinstalling did not remove the cache in my case, I had to do it manually. 

     

    BTW, thanks for setting up this forum. It is way better than patters blog software and the endless comment stream!!!

    That’s what I thought too when I was trying to get some help on the blog.  No problem, I hope more users will join to ease the pain of managing CrashPlan on our NAS’s! As you can tell I’m not the most savvy guy at managing it. 😉

    #331

    Grant Nakamura
    Participant

    I thought I should report back on what I found out after compacting my backup sets, which took a long time.

    Anyway, no joy after the compacting. So, I tried splitting up some of my backup sets to make them smaller. That seemed to help a bit, but still had frequent restarts.

    I then started experimenting with heap sizes trying to find out if that was the issue and it was. After several tries I found that for my backup sets the optimal heap size is 2880 MBytes. That doesn’t leave me with a lot of room for other processes, but at least I’m getting my cloud backups done now.

    #332
    an
    an
    Keymaster

    I thought I should report back on what I found out after compacting my backup sets, which took a long time. Anyway, no joy after the compacting. So, I tried splitting up some of my backup sets to make them smaller. That seemed to help a bit, but still had frequent restarts. I then started experimenting with heap sizes trying to find out if that was the issue and it was. After several tries I found that for my backup sets the optimal heap size is 2880 MBytes. That doesn’t leave me with a lot of room for other processes, but at least I’m getting my cloud backups done now.

     

    Thanks for that. I think in the end it’s nothing we can pin point, it’s more like there a few procedures that help us get it back running. As for memory, I’ve just now checked how mine was (for a two set backup, one with 185k files, 1Tb, and the second 145k files, 330Gb):

     == MEMORY End of backup; maxMemory=1776.50MB, totalMemory=1776.50MB, freeMemory=1073.80MB, usedMemory=702.70MB

     

     

     

     

    #334
    an
    an
    Keymaster

    ALso, I ended up reducing my java heap size with this info, down to ~1200Mb. It was set to 1800 (I have 2Gb of total RAM) and this was seriously bottlenecking my DSM’s file/video server performance, even with SSD caching.  It’s much better now.

Advertisement
Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.
https://i2.wp.com/crashplanbackup.com/wp-content/uploads/2015/11/crashplan-fix.png?fit=512%2C512&ssl=1https://i2.wp.com/crashplanbackup.com/wp-content/uploads/2015/11/crashplan-fix.png?resize=150%2C150&ssl=1anHome › Forums › CrashPlan on Synology DiskStation NAS › CrashPlan stopped backing up (solved) This topic has 12 replies, 2 voices, and was last updated 1 year, 12 months ago by  an.Viewing 13 posts - 1 through 13 (of 13 total) Author Posts November 6, 2015 at 00:13 #197 anKeymaster Hi, Just wanted to let you...Unofficial Help & Support Forum for CrashPlan, Cloud Backup and Cloud Storage Solutions - Find Help, Support and a Knowledge base

Here's what other Users are reading:

Affiliate Links
Advertisement

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close