Rman plugins and file names patterns

[tinto1970]

Hello, at a client who had VBR 12.1 and RMAN Plugin 12.0

(the manual says: Veeam Backup & Replication supports the two latest versions of Veeam Plug-ins. For example, Veeam Backup & Replication 12.2 supports Veeam Plug-in 12.2 and 12.1.)

the files on the repository had human-readable names, like:

`dbname_daily.vab`

After updating VBR and the Plugin to 12.2, the names became alphanumeric strings like:

`009324324-dsfsjhweq--…..vab`

Since, unfortunately (as it shouldn't be done), the client manually deletes these files to perform a sort of manual GFS retention (again, this is not supported), I have a question:

Has anyone had or remembers having a VBR 12.2 with Plugin 12.1? In that case, how are the files named?

Thanks!

[PetrM]

Hi Alessandro,

The naming convention was already changed in 12.1. Instead of creating multiple backup files, the plug-ins now reuse the same target backup file, which consolidates data produced by multiple backup sessions. This approach significantly reduces the number of backup files, relieving the backup storage and configuration database from additional load while accelerating repository rescan.

In fact, all of the mentioned requests are valuable: GFS and increased visibility of RMAN file names are included in our roadmap, but I cannot provide ETA.

Thanks!

[kratos]

Hello PetrM,
could you perhaps help us understand how the current naming scheme works? From my perspective, it’s a bit unclear.

If you back up an Oracle database on a Windows server using the Application Plugin to a Windows repository, it looks as follows:

%name of repo%\VeeamPluginUser_WinRman_%id1%\
%id2%.vab
%id2%.vasm
%systemname%.vacm

1. Only one system name is always specified in the name of the vacm file, even if multiple servers are included in the job. Is that correct?
2. For the directory "VeeamPluginUser_WinRman_%id%", what is the exact functionality? If I delete a job and create a new one, it continues to use one of these directories. Where does this ID come from, and what does it mean?

Regarding the copy jobs, it behaves as follows:

%name of repo%\%name of copy job%\%name of backup job%+%systemname%+"a text string that is cut off after 50 characters begins with 'Oracle back'"
%id3%.vab
%id3%.vasm
%name of backup job%+%systemname%+"a text string that is cut off after 50 characters 'Oracle back'".vacm

It's somehow quite unclear, are there any further documents or best practices available on this?

Best regards,
kratos

[PetrM]

Hi Patrick,

1. We have one backup per standalone job, so we only need one system name
2. The ID is automatically generated based on various source server parameters that remain constant at the operating system level and serve as unique identifiers (such as BIOS UUID)
3. Regarding backup copy, the limitation for the maximum number of symbols is needed to prevent potential issues with file systems that do not support long file paths

There is no documentation or best practices regarding modifying this naming convention: users are not supposed to modify it in any way. However, could you please provide more context about the problem you are trying to solve and why you are interested in knowing all of this?

Thanks!

[kratos]

Hi PetrM,

thank you. There’s actually only one reason we need to understand the directory structure, and that’s for backup to tape as a file. If there were regular GFS support for the Oracle Application Plugin, this wouldn’t be necessary, and we could ignore the directories (as we do with the Linux Hardened Repos).
It would be great if the paths were shorter and could be customized.

Initially, we considered using a combination of regular Veeam integration and the Application Plugin, but we have since decided against it.

Best regards,
kratos

[PetrM]

Hi Patrick,

Got it. First, file to tape is unsupported for plug-in backups, and we cannot guarantee successful restore in this scenario. There are potential data loss issue, some of them are related to the fact that we reuse the same backup file for multiple backup sessions, and keep the file open for 24 hours by default. I don't recommend using file to tape job for plug-in backups. This is the most popular feature request which has significant value, and I hope to get it in one of our future releases, but I'm not ready to give ETA.

You may consider the following workarounds:
1. To use "KEEP" parameter for GFS processing as it's described in this blog post
2. To use plug-in backup copy job as a source for file to tape and keep data transfer disabled in backup copy settings during file to tape runs

Thanks!

[tinto1970]

Thanks Petr, this is valuable information for moving RMAN backups to tape, which is often requested by many of my customers, who need very long retention for their Oracle backups. I need to correct some mistakes I have made, just in time.

Thanks so much. This post should be put in great evidence, I will blog something about this, asap.

[tinto1970]

https://blog.tinivelli.com/rman-backup- ... 3118ce6cf5

hope I did it right

[PetrM]

Hi Alessandro,

I like this blog, very useful and valuable summary!

Thanks!