v9 Oracle redo log backup mechanism - improveable!

[zwen]

I would like the mechanism of the new oracle redo log backup to be improved.

My biggest concern is the fact, that Veeam B&R copies the redo log files to the "/tmp" directroy when backing up (Linux-Server , donnot know about Win).
This is a solution that might be o.k. for smaller databases with only few changes in data. For large databases with heavy data modification which results in a big amount of redo logs beeing produced, this is a "no go" in my point of view.
TMP-Directories with 2-4GB of free space are usually sufficient for an oracle database server. But this won't work for veeam backup.
There needs to be at least as much space in TMP availabe for veeam as the amount of redo logs the database genereates in one redo log backup cycle (default 15 min. in Veeam) in worst case!
But that is hardly predictable. In addition it is also not predictable how much of the available space in TMP is used by other applications on the server at any time.
It gets worse when backup is under maintanance for a certain time. After maintananace there will be even more redo logs to backup in one cycle.
Sooner or later TMP will run out of space. Redo log backup will get an error and the situation will get even worse since backup will halt and even more redo logs that need to be backed up in the next cycle will be produced by the database.
This is what I encountered in my first tests and Veeam B&R didnot seem to recover from this scenario by itself. I ended up delete the tmp directory manually and triggering the parent job that truncated all redo log files.
To have a robust solution the only way would be to size the tmp directory to the same size as the oracle archive log area, but this is a big waste of storage, since most times this space would not be used.

And why copy the files anyway? They are already there in the archivelog directory, ready to be picked up by veeam. Why not get them from the original location? In that case nobody has to worry about free space in TMP.
I think when backing up a machine or database, free space on the server to be backed up should not be an issue...
An alternative would be to detect the filesystem full condition and only copy that much files to TMP that will fit there, then transport them to the repository, delete them from TMP and then copy the next files ...

I am more than satisfied with the other veeam capabilities and I was hoping with the v9 oracle integration I could get rid of the HP Data Protector. So I would very much welcome the described improvements, I am not feeling save about switching database backups to veeam at the moment.

Cheers
Sven

[Gostev]

Hi Sve, thanks for your feedback. I will check with the devs for the reason behind copying redo log files into /tmp before shipping them. Seems like a redundant operation indeed. Thanks!

[btridon]

Hello,

+1 zwen, we need to extend this partition, it's very annoying to cannot have the possibility to change path.

[Gostev]

Well, changing path is certainly possible (there is a registry key on Windows, and it can be done via XML file on Linux). Please contact support to obtain those, as we don't currently have this capability documented, so they will need to work with R&D to get this information and create a KB article.

In regards to copying redo log files to /tmp first (instead of obtaining them directly from disk), devs explained me the reason for this implementation.

In short:

1. For local files, this was implemented for reliability reasons to ensure log backup does not fail in certain corner cases. We have discussed those, and decided that we can remove this logic completely, as those corner cases are extremely unlikely.

2. For ASM, this is looks to be a mandatory step. We can potentially reduce /tmp disk consumption (which would require pretty significant changes on our end), but we can't eliminate it completely. As the result, we will keep ASM logic the same for now.

Thanks!

[pirx]

I'm not sure how this will with large Oracle DB's. We have some > 10 TB Oracle DB's and a copy of the log files to /tmp will be huge I think.

[DChiavari]

For anyone interested, the KB article is here: https://www.veeam.com/kb2093

[wuerzburger]

A restore over Veeam Oracle Explorer should check the available space in /tmp (Linux Server) folder if it is sufficient for restore (the archive logs are restored there before they are replayed to the database).

We made an restore over Veeam Oracle Explorer for a 1.2TB Database and at 98% it stopped with error because there was not enough space for the archive logs in /tmp. So we have to grow the /tmp space and restart the restore which took us another 7h to reach 98%.

[veremin]

You can change the default location by modifying corresponding xml file. Thanks.

[wuerzburger]

We would have changed the default location, if there were an info before restore of how big the log files for restore are!

[veremin]

Discussed that issue with QA and dev teams. More advanced logic will be implemented in one of the future product versions.

The logic will validate the free space in a given directory in advance. Also, there will be some enhancements related to logs upload and apply processes.

Thanks.

[franklincampo*007]

I have a 1.2 TB archivelog mode 11g database on virtualized x64 oracle linux SOP in vmware, and when trying to restore a backup, veeam throws insufficient space error on volume / TEMP has 8.9GB expected value 1.2TB. I understand that the TEMP is a transaction area where veeam mounts the backup and later writes it to the VM machine, this does it in case of errors in restorations, have a return point to undo the operation. I turn to your valuable help and knowledge to resolve this error.

[wishr]

Hi Franklin,

Welcome to Veeam Community Forums!

If you are experiencing an error when using any of our products (which is a bit unclear from your post), please open a support case with our technical support team directly. Troubleshooting through the forum is not possible and is handled purely by support engineers. We would be able to assist if you share your support case ID once you have it. Please note, that you should provide a support case ID when posting about any technical issue or an error otherwise your post will be eventually removed by forum moderators.

If you have a question that is addressed to product managers e.g. best-practice, product design or functionality related question or a feature request - please let us know.

Thanks