I would like to backup to a destination folder directly, avoiding the need for copying a backup from the temporary folder location to another location on the same disk.
I followed the advice in Using temp folder for backups which seems to suggest that if the backup for the database TestDB is F:\backups\mssql and the temporary folder location is F:\backups\mssql then SqlBackupAndFtp would create the backup and not need to copy it to the folder destination.
But in my testing it does not appear to work this way:
When “Place the backups for each database into its own subfolder” is enabled; it creates the file in the root folder (“F:\backups\mssql”) and then copies it to the database subfolder (“F:\backups\mssql\TestDB”), so the copy operation still occurs
When “Place the backups for each database into its own subfolder” is not enabled; it creates the file in the root folder (“F:\backups\mssql”), copies it to itself and then deletes the backup as part of cleanup.
Is there a way to back up directly to a folder, bypassing the temporary folder?
That is disappointing but please do put this in as a feature request as we would save hours every week when we take full backups of each database on our production servers.
Currently, when we take a full back up of just one of our databases:
It takes approximately 60 minutes to back up the database to the temporary location including verification
It then takes approximately 90 minutes to upload the database to S3 including verification
It then takes 50 minutes to copy the temporary backup to another location on the same disk including verification
We could save 50 minutes on our backups for this one database alone, across three servers that’s 150 minutes and this is just one of over 10 databases we have on each server.
It would be a huge productivity boost for us if the temporary backup was kept as the main backup instead of being copied and later deleted.
Hello, I just wanted to check in and see if there’s any movement on this feature? It’s become a pain point for my organization and I’d love if it could addressed soon.
We apologize, but for now, that option is unavailable. We anticipate it will be added in the future, but there is no specific release date at this time.
If you have any other questions, please feel free to let us know.
Thank you for using SQLBackupAndFTP, and we apologize for any inconvenience.
Hi,
Just wondering if there is any update on this feature request. We have a couple of instances where the backup size is very large and it is cost inefficient for us to keep a large disk available just to cope with the massive .bak and .zip that are generated locally. Even if we could stream the .bak directly to AWS and then do the zip locally that would be a big help.
Thank you!!
This workaround is insufficient; I wrote in the OP that this does not avoid the copy operation when “Place the backups for each database into its own subfolder” is enabled.
You can set the temporary folder to be the same as the destination folder. This helps avoid additional copy operations and minimizes extra space usage on another drive.
However, when ZIP or 7-Zip compression is enabled, SQLBackupAndFTP still needs to temporarily create the raw uncompressed .bak file before creating the archive and deleting the raw backup afterward. The raw .bak can be large because it is not compressed.
If disk space usage is the main concern, you can instead:
enable Backup options → SQL Server backup compression → ON
completely disable ZIP / 7-Zip compression
In this mode SQL Server writes an already compressed .bak file directly, so the large temporary raw .bak file is no longer created before compression.
As stated, if “Place the backups for each database into its own subfolder” is enabled it is not possible to simply create the file once. The motivation for this is not to save disk space - we have ample. The aim is to reduce copy transfer times.
I refer to my previous comment about the time savings that can be achieved if this was fixed:
It takes approximately 60 minutes to back up the database to the temporary location including verification
It then takes approximately 90 minutes to upload the database to S3 including verification
It then takes 50 minutes to copy the temporary backup to another location on the same disk including verification
However, the issue is that SqlBackupAndFTP was originally designed around a different concept — as software intended to send backups to multiple storage destinations simultaneously.
Directly writing a backup to a single destination conflicts with this architecture and would require significant redesign of the backup pipeline.
We are considering the possibility of introducing a separate type of backup job for direct-to-destination backups in the future, but this is not something we expect to add in the near term.
