Can't create new backups

Are you using apache server? Is it configured to use .htaccess files?

Did you ever solve this? I'm seeing same problem. Not been able to run a scheduled update since upgrading to 6.x-2.4 earlier this year.

Try putting the backups in a folder outside /sites. I put my back-ups in a folder, like a new folder called /db, in the same level as the main drupal installation. Works fine even with 6.x-2.4.

Yep above suggestions should work. Sometimes web hosts give you a tool to 'password protect' a directory. That might work too in a pinch. Whatever you have to do to prevent the public from accessing your backup files over the web. The module won't backup to a directory that hasn't been protected from the public in some way.

Folder permissions are not the issue here since it is access over the web (ie at: http://example.com/sites/default/files/backup_migrate/manual/mybackup.sql) that it is checking for and that is not controlled by unix file perms. B&M should set the web server permissions on that folder automatically (using a .htaccess file) but something about your setup is preventing it from doing so.

That's exactly it. The BAM problem was on a Windows server and the .htaccess file hadn't been copied into the nominated folder. I'd reverted to 6.x-1.x in the interim on Production.

Thanks @ronan. Not sure if @juliaset ever sorted her problem out.

We have been encountering this issue on one of our websites running Drupal 7.

Our setup is as follows:
In the root drupal directory, we have a folder called "current_db_backup", every 4 hours cron runs a script that clears out that folder (leaves the .htaccess file) and then runs backup and migrate with a custom destination (current_db_backup) and a custom profile to create a new Database backup, and then the script automatically commits and pushes to the repo (that way, we have the latest version of the website in the repo at really any given moment, as well as having database and code backups going back at 4 hour intervals, allowing us to rollback even if we miss a website destorying error for a day or two.).

Now, when I go in (as root) and with drush run "bam-backup db (destid) (profid)" I get an error saying:

file_put_contents(var/www/stanwich/current_db_backup/.htaccess): failed to open stream: No such file or directory file.inc:498                                                                        [warning]
WD security: Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your var/www/stanwich/current_db_backup directory which contains the following lines: SetHandler      [error]
Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks
fopen(var/www/stanwich/current_db_backup/test.txt): failed to open stream: No such file or directory destinations.file.inc:209                                                                        [warning]
file_put_contents(var/www/stanwich/current_db_backup/.htaccess): failed to open stream: No such file or directory file.inc:498                                                                        [warning]
WD security: Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your var/www/stanwich/current_db_backup directory which contains the following lines: SetHandler      [error]
Drupal_Security_Do_Not_Remove_See_SA_2006_006
Deny from all
Options None
Options +FollowSymLinks
fopen(var/www/stanwich/current_db_backup/test.txt): failed to open stream: No such file or directory destinations.file.inc:209                                                                        [warning]
Could not run backup because the file could not be saved to the destination.                                                                                                                          [error]
WD backup_migrate: Could not run backup because the file could not be saved to the destination.         

This is the only website we have had this problem with, even with pretty much an identical set up. I made my own .htaccess file and this error was still happening. I tried all sorts of permissions on the folder, ranging from 1777 to 666,444,222 and pretty much any combination of the above I could think of. Tried changing the owner to www-data and root, same problem.

The only thing I can think of now is that this website, because it is still in development, is using an http password. I am wondering if this is somehow preventing BAM from reaching a directory inside (because it won't even backup to the default directory with default profile either) the root directory. I will be getting rid of the http password soon and will test to see if that was indeed the problem, and if it is, then perhaps in a future release there should be a way to include a username and password for an http password protected website.

***EDIT***
Sorry, I didn't realize how old this thread was, but I did a search for several different terms and this was the most relative thread I could find.
***EDIT***