Manually run full backup

[BostjanUNIJA]

Hi.
We have 1 job that is backing up multiple VM's inside that job.
Is there way to trigger full backup only for 1 VM inside this job, or is that technically impossible to do it?

[PetrM]

Hi Bostjan,

The only idea which comes to me is to exclude all objects from processing except this VM and run Full backup. But why do you need to run full backup out of schedule? Please have a look at Quick Backup, perhaps it would fit better your use case despite it creates incremental backups.

Thanks!

[BostjanUNIJA]

Hi. Tried with Quick backup option first but it gave me an error: "unable to perform quick backup for VM. Reason: No full backup found for this item.

But why do you need to run full backup out of schedule? -> One of the VM's is SQL server which had DB's with simple recovery model. We have switched recovery model to FULL on all the databases, and now it will not truncate logs until the next scheduled full backup will be done. That's why we would like to trigger full backup only for this specific SQL VM, so logs will not increase before full backup will happen (and full backup happens once a month only)....
I like the idea with exclusion all, running full backup, then including the rest of VM back.

[chris.childerhose]

Would it not be quicker to just create a new backup job with just the SQL server and run the full backup? Might be the quickest option at this point.

[BostjanUNIJA]

I was also thinking about that option. But I'm not sure if we need to explicitly enable application awareness on this job or is that not necessary and primary job will automatically truncate logs, after the full backup is being made?
thanks for the reply

[chris.childerhose]

If you create a new job then you do need to enable Application Aware processing to have Veeam truncate the logs. You can then disable that new job and allow the other job to continue processing the SQL server after that.

[BostjanUNIJA]

Thank you for clarification. You have helped a lot!

[PetrM]

@BostjanUNIJA May I ask you to clarify this statement please?

We have switched recovery model to FULL on all the databases, and now it will not truncate logs until the next scheduled full backup will be done.

Do you see an error message during truncation? Not sure that I see how the backup type whether it is full or incremental can be related to logs truncation. It should be enough to just enable logs truncation on the existing job, if not, I'd dig deeper into this behavior.

Thanks!

[BostjanUNIJA]

@peterm - thank you for your reply
- Application awareness job aka SQL dump transaction logs were already enabled inside Veeam job
- Changes we had made were done afterwards, yesterday we had reconfigured all SQL databases from SIMPLE recovery model to FULL

After changing recover model on SQL side, Veeam Job is throwing an error that dump of transcation SQL logs cannot be done until at least 1 full backup is being made...

[PetrM]

Hi Bostjan,

An incremental run must be enough, I've just confirmed it with my colleagues from QA. May I ask you to open a support case and share case ID with us? The behavior does not seem normal but so far you can use any of the workarounds proposed above.

Thanks!

[HostedBDR]

Bostjan,

If your DBs are in full recovery mode the logs will not truncate with a Veeam incremental (or with any other product) they will have to be in simple mode to have that happen. If you’re concerned about log truncation, then may I ask, why are you using Full recovery modes? By definition if you want the logs truncated, you use Simple mode.

The ‘FULL’ mode doesn’t actually truncate the logs, so the ‘last backup date’ won’t change with a Veeam backup, the only way to change the SQL backup date would be to go into SQL and do a full backup. Full mode, doesn’t truncate the logs, even if the event log says success, it doesn’t do anything. Only Simple mode does, this isn’t a ‘Veeam’ thing, it’s an industry standard. Just Google SQL Full mode and truncation, the answer is no, regardless of product. If you want logs truncated, it must be in Simple mode.

Hope that helps, Cheers.

[Spex]

There is an unconventional way to trigger a full backup - if you use scaleout repositories:
- Locate repo (part of scale out) where vm is stored
- Seal repo
- Start quick backup for this vm
- Wait for the backup to start
- Unseal the repository

Happy backup!
Spex

[janezk]

Bostjan,

I have a lot of SQL servers in my jobs and I have separate jobs for those servers as this jobs are somehow "special". I recommend you do the same. In this way there you have more flexibility and you can set also settings specifically eg. alarms, priority, etc...
I have special jobs for all machines that have the Application Aware possibitlity ( eg: SQL, Exchange, Sharepoint )

Regarding this post and the statements in it I think they are mostly wrong or misleading so I have to adress it in order not to leave it like this for future readers:

Bostjan,

If your DBs are in full recovery mode the logs will not truncate with a Veeam incremental (or with any other product) they will have to be in simple mode to have that happen. If you’re concerned about log truncation, then may I ask, why are you using Full recovery modes? By definition if you want the logs truncated, you use Simple mode.

The ‘FULL’ mode doesn’t actually truncate the logs, so the ‘last backup date’ won’t change with a Veeam backup, the only way to change the SQL backup date would be to go into SQL and do a full backup. Full mode, doesn’t truncate the logs, even if the event log says success, it doesn’t do anything. Only Simple mode does, this isn’t a ‘Veeam’ thing, it’s an industry standard. Just Google SQL Full mode and truncation, the answer is no, regardless of product. If you want logs truncated, it must be in Simple mode.

Hope that helps, Cheers.

Let's put it as simplified like this: with DB's in simple mode SQL "automatically" truncates logs and this mode is usuallly not used for "serious" production
With DB's in other modes you ( or actually Veeam) has to truncate logs ( and you don't do it manually as you break the backup chain)
In order to do this you have to enable Application Aware processing:
https://helpcenter.veeam.com/docs/backu ... ml?ver=110
There is plenty of resources on how to do it properly and set up everything that you have the best possible scenario for a quick and efficient recovery in case needed.

BR

Janez

[BostjanUNIJA]

Janez hvala (thank u). All clear.

[janezk]

Bostjan,

ni problema... not a problem. Forums are a great leraning tool and a great community to resolve any dillemas...

LP Janez

[HostedBDR]

Regarding this post and the statements in it I think they are mostly wrong or misleading so I have to adress it in order not to leave it like this for future readers:

Nothing misleading about it. Try it. The date will change in SQL for last full backup on a db in FULL, however the DB doesn't shrink. As with everything, try it. Plenty of documentation to support this, Full mode, does not truncate the logs in the same manner as one in simple mode. Cheers.

[Martin Damgaard]

We run SQL 2019 cluster with about ten DBs in availability groups - this requires running in FULL log mode.
I can absolutely say that when we run our Veeam backups (with application aware enabled) those logs ARE getting truncated!

[david.domask]

I think there might be a small misunderstanding -- Veeam Full/Incremental backup doesn't influence the SQL processing type -- both do a __SQL Full Backup__ via VSS. Truncation is a separate process that Veeam performs during Guest Processing and it happens if the DB is in Full Recovery Mode: https://helpcenter.veeam.com/docs/backu ... ncate-logs

> however the DB doesn't shrink

This is not a factor of truncation -- truncation simply frees up pages to be overwritten, it does not perform a DB shrink to reclaim space.

https://docs.microsoft.com/en-us/sql/re ... Truncation

>Log truncation does not reduce the size of the physical log file. To reduce the physical size of a physical log file, you must shrink the log file. For information about shrinking the size of the physical log file, see Manage the Size of the Transaction Log File.
However, keep in mind Factors that can delay log truncation. If the storage space is required again after a log shrink, the transaction log will grow again and by doing that, introduce performance overhead during log grow operations.

I suppose that may be the confusion.

[janezk]

I think David here gave a very good explanation.

Nothing misleading about it. Try it. The date will change in SQL for last full backup on a db in FULL, however the DB doesn't shrink. As with everything, try it. Plenty of documentation to support this, Full mode, does not truncate the logs in the same manner as one in simple mode. Cheers.

It's obvious that you mixed log truncation and shrinking of log files.
as Martin stated in SQL cluster with AOAG it is required to run in FULL log mode. Simple mode is not an option.

We have some SQL single instance on single server for a very primitive application that is set to simple mode. But if you want to have "serious" production with the possibility of point in time restore then simple mode is not an option...
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

br Janez