How should I back-up an application database during a release

Consider the following scenario:

1. There is a Unix user named gaius on the Oracle server with external authentication, so in Oracle there is a corresponding user called ops$gaius. When logged into a shell, I can also log straight into my Oracle schema, and my cron jobs don't need a password embedded in script either.
2. Remote OS authentication is permitted, on the assumption that the LAN is 100% secure and the clients can be trusted (same as rlogin/rsh used to be normally allowed)
3. An attacker gets his or her laptop onto the LAN by whatever means, knows that I work there, and creates a local user on their laptop called gaius and runs SQL*Plus as that user
4. Oracle sees (i.e. OSUSER in V$SESSION) is gaius and logs that remote user in as ops$gaius

That's not only laughably easy to spoof, but putting on my cynic's hat, Oracle can't make any more money selling you their fancy single sign-on product... Which by the way does fulfill all the points you raise as advantages of OS-level auth. Two passwords better than one is entirely spurious; most people will set them to be the same anyway (there's no mechanism in Oracle to prevent this).

The general principle is that it is extremely difficult to defend in software when an attacker has physical access. And never trust the client.

From the description you gave I don't think security is the concern here. As you said your application receives data from multiple sources. The security comes/implemented when you have role based security kind of things on retrieval/access methods of that data. I am guessing the there must be first some kind of consolidation, analysis, reconciliation etc... happening before the data is is being presented to user.

In such cases separate schema is the best way to keep source data intact,not only during staging but even a original copy of source data; Just in case you want to troubleshoot later what data has been received from specific source.

Depending on what are the data providers but if this is financial data it is very likely the provider update source data format, add/remove columns etc.. frequently. if multiple source starts doing this at the same time it will be difficult to manage those changes if you have one consolidated schema design. but if you had seperate schema you know that this changes is not going to affect other sources data.

Second scenario if you are expecting you application as a source providing Some sort of consolidate data or source specific data to another subsystems then with separate schema you have more control and flexibility it terms of how and what you want to share. If you have same schema; sharing data will becom pain by Selecing some tables, or custom roles, or writing alternate APIs.

Well down side of having seperate schema is you have to use fully qualified object names to a life any unexpected results. Also if you have any scenario wher you might use open/distribute queries, linked servers, etc... Remember that it allows only two level of object name resolution. Think about other things like SQL agent jobs, and other features you might be using and check it supports fully qualified object name resolution or not.