I think that you are bringing up a couple of separate concerns, and that they cannot be collapsed into a single concern.

For example, a host or a renter might be subject to a DDOS attack (especially a host) that makes business difficult. But it's much easier to DDOS a single host than it is to DDOS an entire file, because you need to know all of the hosts that have that file (not always public knowledge), and you need to have enough resources to DDOS a large enough number of hosts to make the file inaccessible, and that number could be dozens of different hosts, which is a different level of attack than DDOSing a single host. As far as I am aware, there's not a whole lot that you can do about DDOS attacks (other than work with a service like CloudFlare) - if someone wants to send you network traffic, there's usually a way for them to do it.

The Sybil attack, or 'not really redundant storage' is a different concern. When uploading files to the network, you want to upload to many different hosts (as a part of the security model), and you want to be sure that these different 'hosts' aren't all putting your data on the same physical disk. There are two components to this. We can solve one of the problems pretty easily by encrypting the redundant pieces using different keys. So, we can force the network to store the full redundancy of the file, though this technique is not enough for guaranteeing that the data is not on multiple separate physical drives.

You can introduce a monetary component to make Sybil attacks expensive. On the Sia network, for example, all money transferred between renters and hosts is measured on the blockchain and includes a component of proof-of-burn (in the form of siafund fees). The proof-of-burn component means that this activity is expensive to spoof, mitigating simple Sybil attacks and forcing attackers to spend significant monetary resources executing an attack.

Depending on how much you trust something like an IP address, you can use IP addresses to get a sense of the actual physical location of the data. But you can also do better than that if you've got multiple servers spread over a large geographic area. You can do ping-time challenges to the hosts that are storing your data. If a host claims your data is in China, and another host claims your data is in America, and you've got a server in each, you can do challenges that require the host to respond in under X milliseconds. The laws regarding the speed of light give you a way to be absolutely certain that your data is being stored in both China and America, because the ping time on the challenges from your server in China to the host in China will be very small, and the ping time on the challenges between your server in America to the host in America will also be small.

So, if you are willing to use a more elaborate setup, you can definitely get proofs (based on the fact that data cannot travel faster than the speed of light) that your data is in two different geographic locations. And depending on your trust model, you can outsource these challenges to the network (have someone else do the challenges on your data and trust their results).

The really nice thing about both DDOS and Sybil attack prevention is that it's not a consensus layer problem. Consensus protocols are notoriously difficult to upgrade, and even more difficult to get right, but we don't have to worry about maintaining consensus. We can update nodes and improve techniques in ways that don't require the whole ecosystem to upgrade simultaneously, so as we continue to think of better ways to handle DDOS and Sybil attacks, we can incrementally push them out to the network.