Any changes that were made since the backup are not present in the repository, and everyone will have to do a fresh checkout from the restored repository. (The revision numbers have changed, and you'll have a mess if you don't.)
As for salvaging any changes from developer's local copies, yes, that's going to be rather manual. However, "diff" and "patch" are your friends. If you aren't familiar with cygwin, you'll want to get that and get the diff, patch, diffutils, and patchutils packages so you have the 'diff' command and the 'patch' command. You can use the "diff" command to create a file containing the delta between one copy of the source tree and another. You'll want to use it like this:
diff -urN --exclude=.svn fresh_check_from_new_repo old_working_copy > developer1changes.patch
Do that for each developer's working copy.
You can take those files and apply the changes to a fresh checkout using the "patch" command like this:
cd working_copy
patch -p1 -i ...../developer1changes.patch
You will now have a working copy with their changes. (Though without their svn adds, svn rms, and property changes.) From there, determine what needs to be committed.
You can use the "filterdiff" command to take the patch file and filter portions of the changes out, pipe that to patch, and it will apply just those changes.
edit:
Another option:
for each developer, create a branch and checkout that branch, then copy their local copy over the files in that new working copy and commit.
That gets all the work in the repository where it won't get lost. You will then have to deal with conflicts when trying to merge the branches into trunk. At that point, you should be able to use the gui tools to select which changes to keep or toss.
But the short answer is: you've got a lot of work to do since you don't have a very recent backup of the repo... so once y'all are able to work again, setup a much more frequent backup schedule.