Basically, since you're running the backup using the console, I'm assuming on a *nix box, the backup meta files are being created using the permissions of the Cron user so the Apache user can't touch those files (at least it can't REMOVE those files). If you don't know, when a backup is taken a "virtual" layout of your backup store is created in the "working directory" that lays out all the details of your backup state, in the same structure as your backup state. File names match, details about each backup, etc, are all stored in little files in the working directory.

And when you tell Backup Pro to delete a backup, it'll read the details about the backup it's deleting, remove it from wherever you've stored it, and THEN remove the meta file as well. I'd bet you $10 that the file on Dropbox is removed when you manually delete the backup but it's only just the meta file itself that remains. Annoying too I bet.

To get around you have all sorts of solutions ranging from moving hosts, to recompiling your Apache and PHP setup so they both run as the Cron user (all of which are just terrible solutions IMHO), OR you can implement the limit settings within Backup Pro. A couple clicks, a couple key strokes, press Enter/Submit, and you're done.

Do this:

  1. Go to the Settings area of Backup Pro
  2. Implement either Auto Prune Threshold level and/or backup type limits (file and database limits)
  3. Run a backup from the console (<- VERY important)

This works since Backup Pro runs the "cleanup" routing after a backup runs so will take your above settings and use that to manage your backup state for you. In fact, it's best to just let Backup Pro manage your backup state anyway so you don't really need to think about it again.

That said, if you're in a more "I NEED THIS DONE NOW!!!" position (clients, amirite?), you could just "chmod -R 0777" the working directory so the files are writable and then go into Backup Pro and remove them. That'll do it too but it's not a long term solution.