Note: This is related to other issues, but outlines the core issue common to both.

http://drupal.org/node/346084
http://drupal.org/node/383272

The code in the backup_files_main_submit function makes the assumption that the current directory is going to the the main document root directory (e.g. htdocs). This is wrong in a variety of different ways drupal can be installed and cause the module to either not work or require very odd looking backup directory paths.

The specific line (#155) in the backup_files_main_submit function that is the source of this is:

$rp = realpath('.'. $bp. trim($dir));

Suppose you have listed 'sites/all/modules' as a directory to backup and your drupal app is in the drupal subdirectory under the htdocs directory. The code above will pass the string './drupal/sites/all/modules' to the realpath function. So it's obvious the expectation is that '.' is assumed to be the htdocs directory.

However, since this is a relative path, the realpath function will call getcwd() to resolve this. By definition, in a web environment (at least in the Linux & W'doze servers with recent Apache/PhP version), getcwd() returns the path of the "main" script referenced in the URL. E.g., this would be
/drupal and not
. This means the the value passed to realpath can not be resolved to a directory and you get a "Does not exist error.

In addition, another scenario that this code fails is where the drupal URL has been redirected to a directory NOT under the htdocs directory (e.g., via an apache Alias directive that changes the doc location to an EclispePhP workspace or a user home directory). In this case, getcwd() will return something not even close to the htdocs path.

Obviously, since the code has worked for others, this is probably due to some changes in PhP's behaviour. A suggested patch to fix this while still working with older working combinations would be to do the following:

            $rp = realpath('.'. $bp. trim($dir));
// New code starts
            if ( ! $rp ) {
               $rp = realpath($cwd . '/' . trim($dir)); 
            }
// New code ends
            if ($rp) {
               $relpath = substr($rp, $lcwd);
               backup_files_scan($rp, $lcwd, $files);

This works both in Windows and *nix because PhP can handle a mix of backslash and forward slash path... at least in recent PhP versions. It should also allow for backward compatiblity with any "odd" backup directories that had been created prior to this change.