3

The destination for incoming CrashPlan backups on my server (11.04) is

/media/SeagateBig

(SeagateBig is the volume name of my 2TB USB drive).

When the server boots, two things happen: 1) SeagateBig auto-mounts and 2) CrashPlan starts.

The problem is, that often these two things don't happen in that order. Then I get:

  • Crashplan starts
  • looks for /media/SeagateBig
  • doesn't find it
  • instead of waiting for it, CREATES IT

Now it's backing up onto my / filesystem. NOT COOL.

Meanwhile, when SeagateBig finally gets around to mounting, it finds that /media/SeagateBig already exists, shrugs, and creates /media/SeagateBig_ as its mount point.

What I need is a way for the order to be enforced - where SeagateBig mounts and then and only then the CrashPlan service is started.

Unless I learn that CrashPlan can be told to wait for its destination directory, never to create it... which I am also investigating. But the CrashPlanEngine script is installed by the product so I am loath to modify it, as I know I could by having it loop until df greps successfully for "SeagateBig".

UPDATE: More research has led to asking a better question. See this one.

DavidF
  • 178
  • 1
  • 12

1 Answers1

1

I am not sure how Crashplan works, but here are some tips:

  • If it has an automatically startup plan, disable it, and find out which is the executable for Crashplan.
  • Then create a shell script that looks like this:

    \#!bin/bash
    
    sleep 30 && >name of executable<;
    

Note: This will stop the execution for 30 seconds. You can use whatever time

name your script start_crashplan.sh

Make it executable:

chmod +x start_crashplan.sh

Then add your script in the startup.

Sorry if I was of the subject, but I think this way you have maximum control of what you start and when.

Anwar
  • 75,875
  • 31
  • 191
  • 309
bioShark
  • 4,201
  • 8
  • 40
  • 59
  • This is kind of where I don't want to go -- I am trying not to break CrashPlan so that when they send an update it still works. I see that the script that starts CrashPlan has $local_fs and $remote_fs in the LSB but it's running ahead of the mounting of devices in /etc/mtab ANYWAY. – DavidF Dec 01 '11 at 13:42
  • 1
    Just heard from CrashPlan support -- they said, "Modify the script." *sigh* – DavidF Dec 07 '11 at 18:47
  • :) What can you do, sometimes you need to get your hands dirty. – bioShark Dec 07 '11 at 19:42