How can we improve SQL Backup?

Separate .log housekeeping from taking backups

If anything on the Windows side of the house prevents deletion of SQL Backup's own .log files, the Backup Service wastes time hunting repeatedly for said file(s) to delete, which can considerably (in my case from 2 seconds to 45 minutes per database) lengthen the execution duration, meaning that the potential data-loss window grows to the length of each run, which is unacceptable behavior.

Though rare, changing a service account can precipitate this run extension. Though rare, SQL Backup's response is to only warn of a deletion failure, and try again next time.

SEPARATION OF CONCERNS is a well-establish programming paradigm. Why doesn't SQL Backup adhere to it? What, in reality, does a housekeeping task that cleans up old .log files, have to do with the mission-critical job of taking data and transaction log backups?

May I politely request you split the functionality so nobody in future is subjected to delayed backups and the risks associated with backups not being taken at the appropriate interval.

1 vote
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Stephen@JE shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    0 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...

      Feedback and Knowledge Base