SQL log backup change temporary folder

[veremin]

Does SqlTempLogPath regkey look like something you're after? Thanks.

[frankwijers]

Look like, yes. Is, no.
The server is installed as a backup proxy, the services available on this machine are Veeam Data Mover Service (VeeamTransportSvc) and the Veeam Installer Service (VeeamDeploymentService).
So there's no "Log shipper service" available on the machine. I already tried adding it and restarting the services and the backup job, but it had no effect. I seem to be missing something.

EDIT: to be exact, it's step 5 in the link you provided.

[MariusN]

Hi there,

I cannot find any official KB Article for this change - is there something I missed?
Also how does this required change on a physical system behave with Veeam Windows Agents?
Because there is no RegistryKey like that.

Thanks in advance
Cheers!
MN

[manuel.aigner]

I have exactly the same issue.
My log shipping server was unable to copy a 200GB transaction log backup file to it's own c: drive before moving it to destination repo, afterwards all further backups of this sql machine fails. The T-Log grows till out of disk space on log-partition. Then the SQL Server halts.
That's not optimal. How can we repoint this veeam Temp-Dir on log shipping server. We don't have such big C: drives...

[veremin]

I have exactly the same issue.

- Have you implemented the referenced regkey?
- Have you implemented it on the SQL machine, not backup server?
- Have you restarted log shipping service afterwards?

[manuel.aigner]

Yes I've. On DB-Server I've repointed the temp folder from C:\ProgramData\Veeam\.... to P:\VeeamLogBackup. That works as expected. But our problem is the log shipping server which stand between of DB-Server and Repository.
Veeam copies the backup file to log shipping servers C:\Windows\Temp. If the BAK file is quite large (in our case more than 200GB) it's impossible because our Sys-Drives only 100GB large.

[foggy]

Currently there's no ability to redirect temp location on the log shipping server.

[BGA-Robert]

Yea, storing temp data in the C:\ drive on the Veeam server is not great.
When we first started SQL logs backups, this bit us since the pending logs backup was huge and the C:\ volume on the Veeam server filled.

If you really need to mitigate this, you could create a junction to another volume for that folder.
https://docs.microsoft.com/en-us/sysint ... s/junction

[johannesk]

You might also want to consider configuring the SQL server with the 'Compress backups' option, (if it's not configured that way already). That will make the transaction log bacups alot smaller when Veeam triggers them.

Thus you might not need to configure the temp path.

This is the SQL server configuration for compression.

EXEC sys.sp_configure N'backup compression default', N'0'
GO
RECONFIGURE WITH OVERRIDE
GO

[yakamoneye18]

Hey everyone,

a quick question about the temporary location for the transaction log backup: did the default location for this change with Update 4a?
Since the update, we had errors because transcation log backups "took longer than desired log backup interval". This happend always during the same night time, in the same timeframe when the database on this server is copying about 200GB of data from another DB server. Before askin support for it I looked at the logs myself, and I found that before the update, the temporary bak file was saved to c:\programData, and now it is saved on the same disk as the database (drive E:), in a newly created "Veeam" folder (on another DB server, the files are saved in the backup partition, drive G:). The problem seems to be that the disk is in high usage because of the copy process of the sql server itself, so the transaction log copy process now goes about 100-120 minutes, before the update it was 10-20...

My question: did the default location for the temporary bak file change? And what is the logic for the location (on one server with the DB, on another server on an unused backup partition)?

I will try to force the temp file to another location with the reg key provided here, if this does not solve the problem I will however have to get in touch with support.

Regards,

Tobias

[yakamoneye18]

Okay, even stranger - I just wanted to set the reg key, and I saw that the key is already existent and is set to the new strange location, on both servers. We are only 3 persons in the department who can do this, and they all say they didn't. Is there any explenation why this registry setting is created automatically with Update 4a? And is it safe to remove it if I want to reuse the %alluserprofile% folder?

[Gostev]

Yes, the default location did change to the volume with most free disk space - this is documented in the What's New document.

[yakamoneye18]

Hi Anton,

read the What's new several times, and always overread this... Thanks for the hint.

Just to clarify:
- If I delete key, will it reset to the %AllUserProfile%?
- The document says that the process will use the Volume with most free disk space - if later we delete some files and on another disk there now is more free space - will this change at some point? Or will it use the volume with the most free space in the moment of the transportation service installation / job creation?

[foggy]

Hi Tobias, if you delete the key, it will be re-created and set to the disk with the most free space available at the moment. So if you want to set it to some other folder, you need to do this explicitly. (I think this answers both of your questions.)

[ibarizz]

Hello everyone, I have a question that's been bringing me troubles lately with my VMs:

I have a few a job where my vms placed in there are SQL Servers in which we take backup of their transaction logs every 60 minutes.
Based on this documentation, on step 4: https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Veeam Backup & Replication detects what databases currently exist on the Microsoft SQL Server and maps this data with the information kept in the configuration database. This periodic mapping reveals the databases for which Veeam Backup & Replication must process transaction logs during this time interval.
The runtime component backs up transaction log files and stores them as a *.bak file to a temporary folder on the VM guest file system.

What I wanna know is if there is a some kind of rule for Veeam at the moment of selecting a disk where they gonna throw those .bak and .xml files in that temporary folder on the VM guest file system. From what I have seen is that usually the disk where they save those files is the disk where my smdb database is suited, and it can led to a problem if the disk gets out of space which is usual in my scenario. Is there any other way to specify Veeam to use a different disk for storing thes .bak and .xml files?

Thank you so much.

Facundo.

[HannesK]

Hello,
yes, we chose the disk with most free space.

The temporary folder can be changed with the following reg key set on the SQL server.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Key: SqlTempLogPath
Type: REG_SZ

Best regards,
Hannes

[ibarizz]

Thank you Hannes!

[webmaster@pcrb.com]

I did what is recommended, but it doesn't help. Do I need to restart any service? I don't see a recommended log backup service on the SQL server. What is it?

[HannesK]

Hello,
and welcome to the forums.

It's the VeeamLogShipper service on the SQL server. If it does not work, I recommend checking with support.

Best regards,
Hannes

[dasfliege]

Because of recent problems i pick up this thread again:

On our SQL server, the log backup was performed by default to "C:\Veeam\Backup\SqlLogBackup".
I've changed this path to "G:\Veeam\Backup\SQLLogBackup" by settings the "SqlTempLogPath" Regkey in "HKLM\Software\Veeam\Veeam Backup and Replication\".
That has been working fine for a while, but today i've discovered that the free space on the c: drive is almost fully exhausted, caused by the veeam transaction log backup which was writing to the c: drive again.
Is there any reason why veeam is changing the path backup to default? This is quite dangerous, as it may cause the SQL to crash if it just occupies all the space on the c:

[HannesK]

what is Veeam support case number for the behavior you describe?

[dasfliege]

I have not created a case for the problem that the custom path has been reseted.
But i have been adviced to set this regkey during the troubleshooting in this case: 05217700

[HannesK]

then I can only refer to the forum rules - guessing why something failed on a forum is pretty error prone compared with log analysis

[dasfliege]

I thought it might be an expected behavior that could be explained here. Since I don't know when the setting was reset, the log analysis could be tricky.
I will observe the behavior now as i have set the regkey correctly again. And if it resets again, i will open a case.

[veremin]

No, the situation with directory defined in registry changing its path and overfilled default location does not look expected, so our support team need to check the debug logs and find the root cause based on such investigation. If the problem re-occurs, kindly open a ticket and share its number - this is the preferable and jointly convenient approach of addressing technical problems. Thanks!