Exadata exachk.sh

First you need to ensure that that the backup is in your library (surely you know better ways for find it, I put my query):

select
    D.DB_NAME, B.DB_ID, BASET.BCK_TYPE,
decode(BASET.CONTROLFILE_INCLUDED,'BACKUP','YES','NO') as CONTROLFILE_INCLUDED,
BASET.INCR_LEVEL, bapiece.tag, bapiece.handle, bapiece.start_time,
bapiece.completion_time,
round(bapiece.bytes/1024/1024,2) as Mb
from rman.bp bapiece,
        rman.dbinc d,
        rman.bs baset,
        rman.db b
where BAPIECE.DB_KEY=D.DB_KEY
   and D.DB_NAME='SFPROD'
   and BASET.DB_KEY=D.DB_KEY
   and BASET.BS_KEY = BAPIECE.BS_KEY
   and  bapiece.start_time>sysdate-1
   and B.DB_KEY=D.DB_KEY
---   and bapiece.handle like '%.dbf%'
order by tag desc, handle desc    ; 

And... I hate to use "set until time" to restore/duplicate database. It is more human friendly but you can be surprised with an rman error at the end of the restore. Try to find the last commit (SCN) for duplicate process:

SQL> select max(next_change#)
    from v$archived_log
    where archived = 'YES'
    group by thread#;

or with rman:

RMAN> list backup of archivelog all;
--Next SCN

And then:

run { set until scn ... ; allocate auxiliary channel t1 type 'sbt_tape'; duplicate target database to DEVDB; }

There are no architecture differences in RMAN itself. The difference is in the speed of the backups if written to the Exadata on-board storage. So the advantages that Exadata brings in terms of hardware would also translate to advantages in backup speed and MTR (mean time to recovery). But none of those advantages are the result of changes to RMAN.