During a Disaster Recovery check, I got an error while restoring SPFILE from autobackup:

[php]RMAN> restore spfile to ‘/tmp/spfile.ora’ from ‘/rman_backup/control_autobackup_8357269245-20120303-00.bkp;

<em>RMAN-00571: ===========================================================</em>
<em>RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============</em>
<em>RMAN-00571: ===========================================================</em>
<em>RMAN-03002: failure of restore command at 03/03/2011 18:06:11</em>
<em>RMAN-06172: no autobackup found or specified handle is not a valid copy or piece[/php]

I’ve checked all available solutions that I know, but unable to restore it.

I started to confuse if it’s not a backup of the current database, so I used strings command and checked the database name inside the controlfile

[php][oracle @db] strings /rman_backup/control_autobackup_8357269245-20120303-00.bkp | grep prod

PROD[/php]

Prod is the name of my database, so this is the correct autobackup.

I’ve automated the RMAN backup and wrote a shell script which copies newly created backup files to the remote FTP host. I’ve copied the controlfile autobackup  from the FTP host to the test machine for the Disaster Recovery. Suddenly I remembered the mode that’s used to copy the backup files via FTP. It’s NOT binary! I’ve checked the size of controlfile that’s in FTP server with the one which is located at the production database. There were different! So it’s really “not a valid copy or piece” as RMAN states.

I’ve added FTP command – “binary”  to the shell script to switch to the binary mode, run the backup script again and got my backups copied to the FTP server. Then I tried to restore spfile from the backup and of course – succeeded.

So if copy RMAN backups to the FTP server, make sure you’re using binary mode and don’t forget to perform a Disaster Recovery to make sure your backups are valid