Skip to main content

I must be blind as I cannot see from the explanations on On-Demand Data Protection Operations (commvault.com) how the subclient of the on-demand backupset on some client knows where to search for the directive or content files? I mean does it simply search the entire / fs looking for some hints? Where’s Waldo? Do they sit under the Base directory or ?? I understand the concept, but in NetBackup-land you had to at least give it a hint as to where those directives reside. 

thanks

I agree, the documentation and some links send you in circles.

directive file can be anywhere you want it, likewise the content file can be anywhere you want it. BUT the contents of the directive file, pointing it/linking it to content files must have full path to those content files.

/usr/local/my-directive-file1.txt

Which then contains 1 or many references to content files (the content files then have/contain the full path to all the content in which I want the on-demand backup which uses the directive file will backup)

The doc page says this, but it can be a tad confusing if reading it for the first time.

Does this help?


When you configure you first on-demand backup for say File System Agent, it will have a spot in which you have to give it the directive file, that’s when it will all come together. So set one of them up and it will become clearly.


Hmm, so let me get this right - there is no “setting” where one can easily look to know where the directive file sits?? That seems (almost) ridiculous. On the other hand, is the logic that the client already exists and there’s some index of “backups” from the base OS? I mean - how does it possibly go about locating the file?

I saw zero prompt or place to put such path in when adding the backupset (11.28) so this still leaves me hanging. I guess I’ll wing it and see if it locates them.

A regkey or something would be quite useful for documentation sake. Mere mortals like myself struggle - like in the 80’s “try Bud Dry” - don’t ask me why, it just seems overly obscure.


OnDemand backups, using the OnDemand backupSet, are using a file, that contains files with filelists to backups.

This is more ore less indirect, When you start the onDemand Backup (always initiated from the commandline), you specify the file, that contains the file lists.

I find it a lot easier to use the defaultBackupset for an onDemand backup, where you add the file list as parameter and not the file that contains the file lists.

if you save a manual backup as script, you can modify the resulting XML and use it from you external scheduler or commandline tool to initiate backups. (might also work with RestAPI, never checked so far)

You always need to login to trigger a backup/restore. You could allow local_admin to autologin, gives you access to backup / restore for the server you’re currently logged in and member of the local admin goup.

its not like netbackup or even networker.

Commvault is designed with a central approach. Everything is pre-defined in the configuration. Every client initiated activity is more or less a nightmare and only available where necessary ;)

 


I see for the Oracle On-Demand it clearly states “ Supports only Command Line - based backup.”

It does not state that for Unix.

It also suggests scheduling which - how do you schedule something that has to be run via CLI?

“always need to trigger a backup/restore”. Really. 

How are you supposed to schedule a job for a subclient if there’s no content defined for the subclient? Ah, now it makes more sense. Maybe someone could include the hint…

 


ok, got me.
I wasn’t aware of the GUI option to  start an ondemand backup, since for me this request always came with external schedulers to backup dump directories or alike, after the data has been placed there.

If you want to schedule a job, its no longer OnDemand ;)

to schedule a backup, use a separate backupset and/or subclient to specify the content paths you intend to back up.

Orcale / Informix / MaxDB / HANA ... are a completely different story.

The OnDemand backup with Oracle gives you the option to pass a RMAN script to commvault and the backup will be fully visible inside Commvault, like a regular scheduled backup.

But usually you simply run the RMAN scripts directly on the database, which will be registered as oracle cmmandline backup. The RMAN log is not visible in Commvault in case of commandline or logcommandline backups


Yeah I see your point. On-Demand to me means simply defining the content not so much when it runs. Want the thing to run via a plan or schedule but the content changes daily (RMAN related but files only).

This got me going. thanks everyone.


Reply