BackupBuddy was updated to version 7.1.5.3, from version 7.1.5.1. Changelog:

7.1.5.3

• ImportBuddy: cPanel wizard now supports connecting to https URLs instead of just http.

7.1.5.2

• S3 (v2) destination: Fixed undefined index use_packaged_cert.
  Increased retry attempts from 8 to 30 times when backup process_backup() fileoptions is locked due to long PHP runtime.
• mail_error() function now defaults to get_option(‘admin_email’) email if none is set on the Settings page for error notifications. Also helpful if settings get lost.
• mail_error() is now able to function even if plugin settings are missing/corrupt.
• BackupBuddy plugin settings are automatically backed up regularly in housekeeping function.
• Corrupt or missing BackupBuddy plugin settings are now automatically restored/replaced with the last working version stored in a settings backup file in pb_backupbuddy log directory. Protected with random 32char string and anti directory browsing. Error notification email will be sent to admin_email.
• BackupBuddy now automatically backs up and restores its own settings if they become missing or corrupted due to database problems. This will help prevent loss of settings and backups.
• Database and file exclusion lists are now resizable.
• Added new “Delete All Cron Entries” button to Server Tools’ WordPress Schedules (cron) section for clearing out all cron entries for all of WordPress. Useful if a plugin clogs the cron system with too many entries.
• Stash Live: Fixed excluding file(s) already in the catalog not being removed if they have never successfully sent.
• Stash Live: Added new error when modified time is unable to be determined via stat() such as due to permissions to aid troubleshooting of pending files which never send. Ex: Error #8438934: File modified time unexpectly zero (0). File permissions may be blocking proper modification detection on file `/index.php`.
• ImportBuddy: DAT not found error now checks to see if the DAT file is contained within a subdirectory matching the zip file name. This is common if the user unzips the backup zip manually then re-zips the folder, resulting in site contents being inside a subdirectory matching the zip file name.