Best idea to deal with historic data ( Partitioning? ) We have a database with almost 1 billion rows. 

90% of this table is historical data. We don't use it, BUT if we need to use it, it needs to be right here, right now (we work with banks, so, they need things pretty fast).

I'm reading about partitioning in Brent Ozar blogs etc. but I don't know if this is a good idea.

I would like to partition this table but I'm concerned about backups. If doing backups of the database, without backing up this partition, am I going to have a corrupt database in case of a restore, right?

Am I able to restore only the database, without the partitioned file? 

I'm thinking about partitioning the table, throw this file created in a different disk, and just do a backup of the database without this file. 

I really don't think this is a good idea, so I would like to hear about some experiences with this.
We have several huge log tables partitioned by dates, the typical scenario where we just use current month to store data and the rest is queried for support &amp; troubleshooting. We run backups for the whole database, not just single partitions/filegroups as that will imply piecemeal restores later on. And you don't want to be in the middle of the night dealing with piecemeal restores, unless you are really aware of all the steps involved...I'm not. So if in doubt, use partition at will, analyze your scenario to find the best partition function and run a normal backup of the whole database.