The answer to your general question is: Absolutely. In the early days of computing, batch processing was the only way to do anything, and even when multi-user interactive systems were invented, batch-processing capability was the norm for large jobs. And it's still commonly done today in medium and large-scale environments using systems like Sun Grid Engine or Torque.
However, that's probably overkill for what you need. You could set up a more lightweight system to run scripts in a serial queue, but I don't think that approach is particularly well-suited to your specific task. Presuming parallel copies to different drives are acceptable, I think I'd attack it like this:
Create directory structure corresponding to your your target drives:
Set up an incrontab entry for each of these directories, which runs your copy script automatically on IN_MOVED_TO.
Make your script either a) kill any previous instances of the same script when it starts or b) use a
mkdir-based lockfile and block until the lock is cleared.
Then, all you need to do is move files to the various
~/copysystem/drive# directories, and they're all copied magically to your destination.
Especially in case of 4a, you probably want to use
rsync -aP to copy your files, so that you can restart partial transfers from the middle. (Possibly in combination with
--remove-sent-files, if you want to get rid of the originals.)
If you want to skip the complication of using incron, you can still take advantage of making your scripts block on a lock file. That works something like this:
while ! mkdir $LOCKDIR ; do
echo "waiting for lock"
trap rmdir $LOCKDIR EXIT
rsync commands go here....
This works because
mkdir is an atomic operation — if it succeeds, you know the directory didn't exist. That's important, because if you use something like
! -f && touch, there's a race condition. (Same with scanning the process table for rsync commands, or the like.)