[Feature Request] MS-SQL plugin - backup type automatic conversion

[dgaviraghi]

We have created 3 different jobs in order to do full, differential and transaction logs backup:

- 1 weekly full
- 1 daily diff
- hourly tlogs backup

No DB specified in backup command in order to backup ALL the instance's databases.

In case of creation/deploy of a new database, diff and tlogs backup will ignore the new database until a first full backup of it will be done.
Seems that there is not a way to automatically convert/force the diff or tlogs backup for the just created/deployed database into a type=full backup.
This in order to do not loose backup until the first scheduled full.

We have also raised a TT to the support that confirm the behavior by design and suggest to open a feature request here.

So, we are kindly asking to evaluate the implementation of this feature.

best regards,
DG

[PetrM]

Hi Davide,

Why the manual run of a full backup of a newly created database is not an option?

Thanks!

[dgaviraghi]

Hi Petr,
The idea is to avoid human error and lose days of backup in case someone forgets to force a full backup after implementing a new database

thanks,
DG

[PetrM]

Hi Davide,

The request is noted but I cannot give any information about ETA, it depends on many different factors including the number of similar requests which is relatively low at the moment.

Thanks!

[JGranden]

Any automatic conversion should handle this case as well:

Consider this scenario:

daily full backups -> Veeam
hourly log backups (1am, 2am, etc)-> Veeam

2:30pm - by accident, jr dba takes a random log backup to disk. this will break the backup chain.

Should they have done that? NO! of course not.... but how does Veeam handle it?

When Veeam takes a log backup at 3pm, it should detect that the log chain is broken, and either of these are valid options:

1. throw a hard error/fail fast
2. promote the log to a diff or full (to at least re-establish the log chain.) <--Behavior of EMC DataDomain/DDBoost

early V12 Veeam would silently ignore the problem, happily continue to take log backups that you couldn't restore from and leave the database in a state where point-in-time recovery was impossible (until the next full). (well, not 100% impossible if open a support ticket to somehow to retrieve the log data from the veeam repo)

Is this still an issue? this scenario resulted in our corporate policy of "never let veeam manage log backups"

[PetrM]

Hi Jesse,

Our by-design behavior in this case is to show the error and inform you about the problem with the backup chain (idea 1 above). I think you should open a support case because what you describe looks like a technical issue and not like a feature request.

Thanks!

[JGranden]

Please see closed Case #05924133

thanks

[PetrM]

Hello,

@JGranden
I reviewed the case and I disagree with the conclusion provided by our engineer so I asked our support leaders to open a new case for you. As far as I understand, our engineers reached out to you but you decided not to continue the research. Please keep in mind that you always have the option to open a new case for this issue: just specify the previous case number and refer to this forum topic.

Thanks!