It depends of course on the hash function you're dealing with. Assuming it is a cryptographically secure hash function, you're still looking at brute forcing the output: in other words, trying every possible input, computing the hash and then comparing with the output. Finding two inputs with the same output is a hash collision. Consider the MD5 hash function, which is no longer considered secure, the known collision attacks end up flipping more bits across the whole input, so depending on exactly which parts of the input you know, you might be closer to a collision.
However, most hash functions besides MD5 have only theoretical collision attacks, with no known working examples. If you aren't extremely lucky, then you will have to search for exactly as long as for what you know is different from the real input.
Knowing part of the input does reduce the search space of your brute force attempts, especially if you know the total size of the input. Most hash cryptographic functions can be used a checksums, which means they can function on inputs of arbitrary length. So in other words, if you don't know the total size of the input, then you may be searching literally forever.
If you know the input class to the hash function is fairly straightforward (for example, it's an English dictionary word, or a series of words), then you can potentially employ a rainbow table. If the input is sufficiently noisy, the rainbow table becomes prohibitively large, which is why salt is an effective countermeasure.