ИМХО, выкиньте это стильное, молодежное
Как veam делает бэкап?:
- делает alter database begin backup (в вашем случае БД видимо PDB? Veam думает, что таких не существует и у вас обычный инстанс
- делает снапшот виртуалки
- делает alter database end backup
- копирует снапшот в хранилище/на ленту

Теперь представьте - у вас БД хотя бы в 1 ТБ, а вам нужно восстановить только одно TBS? Будте восстанавливать весь снапшот? Сколько по времени? А архивлоги потом как искать будете?
Все равно потом rman нужно использовать. Зачем вам прослойка для rman?

зы. Тестировали - на линух они для нас даже патчи выпускали, но все равно обычный бэкап я rmanом быстрее восстановил и блее предсказуемо, т к понятно что делается(да и любой админ быстрее разберется, чем с этими костылями).
А так у вас скорее всего получится next->next-> finish (причем полный)

Полностью Вас поддерживаю - трэш

1. Снапшот - не бэкап
2. Восстановление БД Oracle несколько более трудоемкий процесс, чем восстановление файлов из файлопомойки
3. Если БД в режиме noarchivelog, то операция ALTER TABLESPACE с последующим shutdown бессмысленна. Это так называемый "холодный" бэкап, тут достатчно остановить инстанс, скопировать файлы(например из снапшота, для уменьшения downtime) и запустить инстанс
4. Если БД в режиме noarchivlog, то файлы из одного снапшота не подойдут для другого, БД не запустится. Если восстановлен снапшот, потом поработали, скажем несколько часов,
и что-то произошло с каким-либо файлом, достать файл из снапшота и подложить не получится, БД все-равно будет неработоспособна, т е придется откатываться на последний снапшот
и эти несколько часов у вас пропали
5. Большая БД в режиме archivelog с большим количеством tablespace, нагруженная. Shutdown инстанса не нужен. Выполняя последовательно операцию ALTER TABLESPACE к концу получим набор несгласованных файлов, требующих архивлоги, чтобы БД можно было открыть.
6. Т к не используем rman скорее всего будет реализован механихзм очистки каталога с архивлогами. Но на нагруженной БД(п.5) очень велика вероятность, что данный механизм сработает между первым ALTER TABLESPACE и последним. Тогда данный снапшот БД будет бесполезен, возникнут проблемы при запуске инстанса после восстановления снапшота
7. Т к не используем rman требуется самостоятельно реализовать механизмы для поиска и определения нужных архивлогов, требуемых для восстановления и запуска БД. Т е нужно реализовать все то, что уже реализовано в rman
8. Восстановление отдельного файла не всегда возможно,например в линуксе это возможно, если используется файловая система ext3/ext4, для xfs(могу напутать) это кажется не реализовано, для ZFS и ASM - точно не реализовано.
Т е в последних случаях придется восстанавливать весь снапшот.

Основная задача процессов бэкапирования на БД - это минимизировать потери данных в случае факапа.
Для этого в оракле есть специализированные средства(тот же rman), который может проверить консистентность бэкапа, восстанавливаемость и т д
К примеру, если используется HP Dataprotector, DBA может использовать rman на хосте для восстановления бэкапов не заходя на управляющую консоль dataprotector. Т е для DBA прозрачно использование ленточной библиотеки, ему даже не обязательно знать как там настроено. ИМХО любой нормальный DBA все равно будет использовать rman для восстановления БД

Так и был совет - не используйте Veeam для бэкапа БД, для этого есть другие средства
Ну а то, что можно быстро виртуалку восстановить - вопросов нет, только там как правило
более-менее все статично

Alex89_NGDЧто купили на том и работаем, выбирать нет возможности... С oracle 12.2, 11.2 всё это крутится в продакшене на Hyper-V бекапится VEEAM уже более года.

rman не нужно покупать - он у вас уже есть, пользуйтесь

Есть два типа DBA
1. не делают бэкапы
2. делают бэкапы

К этому обычно добавляют - есть и третий:
3. Те, кто проверяет, что бэкапы восстанавливаются

Alex89_NGD[ Вот только понимаете есть такие задачи которые RMAN решить не может... например он не умеет дедуплицировать , а при большом объеме БД это актуально.
Зачем каждый раз все бэкапить и дедуплицировать?
Есть инкрементальные бэкапы - тоже своего рода дедупликация
у rman нет задачи дедуплицировать - его задача иметь возможность восстановить БД
есть различные варианты, как уменьшить объемы в процессе бэкапирования БД

Просто оставлю тут

Т е потеря данных за неделю вас устраивает?!

Alex89_NGDSalкак я и полагал, тут все очень просто - нужен ДБА.

А конкретно что не так с ДБА?
Есть регламент , где прописано как требуется резервировать и восстанавливать эту конкретную БД. По РЕГЛАМЕНТУ!!! после КАТАСТРОФИЧЕСКОГО сбоя , на этой конкретной БД важнее скорость восстановление чем потеря данных за день...

Для этого есть другие методы и уверяю вас - это быстрее, чем восстанавливать снапшот виртуалки с БД