You might be able to find bytes that result in your hash, but they probably won't be the same bytes you 'backed up'.

If the data is shorter than the hash shouldn't it be the same data I backed up with reasonably high probability?

I guess you get (infinite?) many results which all have the same hash and one (or more) of them will be shorter than the hash.

No. http://matt.might.net/articles/counting-hash-collisions/

Can you explain the relevance? If I put N items randomly into >> N buckets the chance of there being a second item in a particular bucket is small (as opposed to there merely being a bucket with two items, as in the birthday "paradox").

That doesn't apply here, since the birthday paradox is about the existence of a collision, not that any particular sequence collides.

Most people in the room will still have unique birthdays even if one pair share theirs.

As an aside, sha-1 is smaller than 128 bytes.

From my numerical experiments (I hope I didn't mess up...) using the random oracle model, the probability that a given key is collision-free is 99.6% if the input is one byte shorter than hash, 1/e if input is same size as hash and 6.6e-112 if the input is one byte longer than hash.

And this holds basically irrespective of key size.

If you're planning to brute-force count through 2^(128x8) possible bit inputs, it will be quite a few decades indeed. And you'll need a few spare solar systems to annihilate to get enough energy to drive your counting engine through that many states.

https://security.stackexchange.com/a/6149/1427

The idea is to wait for a preimage attack on sha, not brute force it.