Unable to parse url...

This is related to the security check the module performs so it shouldn't affect the actual backups, but I'm not sure exactly why the url is not being build correctly. Do you have your base_path set to something strange? Do absolute urls work elsewhere on your site (in your rss feeds for example)?

I'm getting a similar error in my log. I am running Backup and Migrate 6.x-1.2 with Drupal 6.16. This error appears when a backup is manual or scheduled. Nothing unique about my config... but if it is significant, I'm running on a development subdomain. This error was from a manual backup I just ran:

Type page not found
Date Thursday, May 20, 2010 - 11:45
User Anonymous
Location http://xxxx.xxxxxxxx.com/sites/default/files/backup_migrate/manual/test.txt
Referrer
Message forbidden.html
Severity warning

-----
Same error appears when my daily scheduled backup happens, except the url is
/sites/default/files/backup_migrate/scheduled/test.txt

Both of these files exist in their default locations:
/sites/default/files/backup_migrate/manual/test.txt
/sites/default/files/backup_migrate/scheduled/test.txt

I peeked, they say "this file should not be publicly accesible" inside. I doubt that drupal's smart enough to flag the misspelling ;-)

@silentway:
Sounds like your error is being caused by the public access security check and is probably normal. I have a longer explanation here: http://drupal.org/node/691556#comment-3076006

@benhameh
Let me know if you have any more info or need any help figuring what's different about your setup.

Is it saving the files there or is that the URL used to download the files? /system/files is a Drupal path that triggers a download of a file in your files directory. It is the mechanism that allows private files and it is the one used by B&M because the backup files should not be publicly accessible. If you are able to access the files at the second URL you list then your backups are probably not secure and you should stop saving them to the server or secure that directory somehow (password protect it for example).

Your original error seems to stem from the fact that Backup and Migrate is somehow unable to create a valid URL pointing to a test file in your files directory. It's possible that either your files directory is specified in a strange way (leading slash maybe) or your base url is not being set for some somehow.

Hmm, I have these entries in my log too, except this is what some others have:
/sites/default/files/backup_migrate/manual/test.txt

This is what my sites have: /files/backup_migrate/manual/test.txt (no "/sites/default" prefix)

My sites are hosted at Go Daddy, and oddly when I try to open the text file right from the Go Daddy webserver, I get redirected to this local URL instead (?!):
http://localhost/files/backup_migrate/manual/test.txt

I'm having the same problem as benhameh. I'm not getting the same error when I do a manual backup using the same profile, only when cron is run from my web host account. In fact, if I edit the backup schedule to run more often, and then I hit cron manually, the backup occurs without an error. It only seems to be when my cron job is activated from my web hosting account.

I checked and I get the permission denied (permissions) message when I try to access the test.txt file. So the permissions appear to be fine -- secure.

I'm running 6.x-2.2 on 6.17.

Here's the cron command I run from my host:
/dh/cgi-system/php5.cgi
/home/user/domain/drupal/cron.php

Ok, can we confirm that the error people are seeing in their logs is that 'test.txt' is access denied? Because that's a good thing. That directory is supposed to be protected. The logs are filling up because B&M is checking that security. It verifies the security of your backup destination every time it runs.

If anybody is having a different issue that is not log noise caused by denial of access to test.txt then please open a new ticket with a description of your problem.

Thanks
Ronan

So you will fix the "log noise," right?

No. The only way to stop the access denied log entries would be to remove the security check and I don't think that's a very good compromise.

If enough people feel differently I may consider providing an option to disable security checks but I wouldn't expose it in the UI since I really wouldn't want most users turning this off.

Ah! Thank you for the explanation. That makes sense. As long as I know that this is a normal and good sign, I'm fine with that.

Thank you for this wonderful tool!