InnoDB log sequence number is in the future 130711 23:03:40 InnoDB: Error: page 23 log sequence number 3336825872455
InnoDB: is in the future! Current system log sequence number 235089.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.


I've never seen or had this error before. The client does not have backups so they need a recovery done. 

I've done MySAIM recovery before but never InnoDB. Is there any tips on how to do it correctly?

From what I've read up on I need to increase a single counter ("log sequence number") which is stored somewhere in the headers of ib_logfile0 and ib_logfile1 or something like that correct?
The only correct solution is to reinstall and restore from a backup.  You say you don't have a backup, but the point here is that the idea behind forcing InnoDB recovery is that you can potentially get the server stable enough that you can make a backup.  Then use it to restore on a fresh setup.

Obviously, make a copy of all the files before doing anything.

Unless there's a memo I didn't get, you don't want to try increasing the log sequence number to pacify InnoDB, because even if you manage to do it, you've still got a server with data corruption in unknown places -- fix the LSN and all you've really accomplished is made InnoDB unaware of the corruption.  Forcing the LSN is pretty much a fool's errand.

Have you tried anything from... 

http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html

The different levels, 1 through 6, cumulatively disable parts of InnoDB with the idea that if you disable enough functionality you might be able to get a successful mysqldump or at least SELECT ... INTO OUTFILE from the tables.

The idea is to use the lowest number that allows you to successfully dump your data, but if this error is occurring at startup like I think it may be, you might just want to go ahead and start with 6.  If the server starts up, then try selecting from tables.  It may crash again and if it does, then write that table off for the moment and move to the next table.

Once you've retrieved the data from the tables that aren't corrupt, you may be able to go back to the ones that don't work, and try to retrieve the data in small chucks with SELECT ... LIMIT ... OFFSET.

Take a look at my answer to this similar question for some additional ideas.  

You may also want to look at Percona's InnoDB data recovery tool as a potential resource, though I've never (fingers crossed) been caught without a backup or a running replication slave, so I've never needed it.