What would happen when USB devices draw more power than the hub can provide?

This is a terrible idea; don't do this!

With electronics, total power in always equals total power out. You have two power sources: up to 2 A from power supply and 0.9 A from upstream port, that's up to 2.9 A total. What happens if drives try to pull more than that?

• If the power supply is of good quality, it won't provide more than its rated 2 A and (at least some) drives won't spin up/will stop abruptly.
• If the power supply is not reliable, it will catch fire.

With daisy-chained hubs:

• If hubs have a diode that prevents backpowering, things get confusing: the power supply of the first hub powers all hubs down the chain, but the last one powers only the last hub. This is super unreliable.
• If they don't, all power supplies are shared between all hubs. This would be preferable.

What's more, HDDs will draw significantly more than rated current for a moment when they spin up. And they spin up as soon as they get power, i.e. simultaneously. Servers deal with this by starting drives one by one in intervals. You can't do this here because you don't have an advanced drive controller; each drive has one in its integrated SATA-to-USB adapter. More powerful power supplies will improve things, but it will still be super unreliable.

Power issues aside, this is still a terrible idea

I don't know how you intend to use this peculiar RAID array, but it's fundamentally flawed.

RAID is not about backup, RAID is about reliability. If you want protection against data loss, RAID is not what you need. So I assume the goal of this project is reliability and availability. Your array is very unreliable, so it doesn't serve its sole purpose.

Once a single drive fails or drops from array for whatever reason, it has to be brought back into the array and rebuilt. Rebuild of a single dozen-TB drive will take days. You want to use 2.5" drives, so we're probably in 500 GB - 5 TB range. Such drives will take between three hours and two days, probably. Now consider this:

• Your power solution is sketchy
• USB is not meant for permanent attachment - drives do disconnect accidentally every now and then
• We're not sure how well this hub will deal with plenty of drives
• These drives either take plenty of desk space with a rat's nest of cables or are neatly stacked, ready to be knocked down
• Neither of them was designed to work with vibrations amplified seven-fold (drive vibrations travel through case, desk, etc.)

With RAID 6 you can lose two drives without data loss, including drives that are pending rebuild. Considering these problems I wouldn't be surprised if you'd be losing drives faster than you can rebuild them. This will be a disaster waiting to happen.

Solution

You need a DAS (direct-attached storage). It's an enclosure in which you can put your drives, configure them as an array and have them presented as a single device. RAID is entirely managed by the DAS itself. NAS (network-attached storage) is also an option, but it will be available over the network rather than directly attached.

DAS and NAS devices are built with multiple drives in mind. Power problems are already solved for you, and disks are attached using SATA connectors and screwed in (3.5" disks are preferable, but you could go with 2.5" + adapters if you prefer them for some reason). Using drives designed for NAS is recommended.

This will cost a lot more, but it will work reliably which is the whole point.

You can reduce the price by buying external drives (they are cheaper than internal ones) and taking them out of their USB enclosures ("shucking"). But you may lose the warranty, you get drives that are not certified for arrays (vibration problem) and you must know what to buy: for example some 2.5" portable drives have USB ports soldered directly into their PCB, without any SATA port.

Some popular DAS brands are TerraMaster and Drobo.

TL;DR: Don't do this.

If you're on a tight budget, scale down and go for a DAS.

This very much seems to be an XY problem. What you're actually trying to achieve based on comments is scaling up storage capacity for a file server in an inexpensive way.

The issue here is that USB is horrendous for any situation where reliability is important for a couple of reasons:

• Power distribution over USB is generally problematic. You can mitigate this by only using powered hubs and powered peripherals, but that doesn't solve any of the other issues.
• The 'bus' is asymmetrical from a latency and efficiency perspective. The further down the chain of hubs something is, the worse it's latency and throughput will be. This can kind of be mitigated by utilizing a balanced tree topology so that everything is at the same nesting depth, but that's not exactly trivial, especially since the USB ports on most computers are actually connected to hubs internally themselves and not directly to the host controller, and it's also not exactly cheap.
• USB connectors are actually rather mechanically unstable. This is actually really important for the original intended use of USB so that you don't damage the ports when you trip over a cable, but it's a very bad thing for storage systems where reliability is needed.
• It's very easy to trigger a bus reset by accident. This isn't an issue for the input devices USB was intended to be used with, but it's a serious problem for storage devices (seeing link resets for SCSI or SATA devices is one of the times you start replacing hardware if you're doing things right).
• Because of how the MSC and UAS standards work, you have t reinitialize the whole device every time you have to reset the bus, which in turn can cause all kinds of nasty behavioral problems when dealing with a RAID array of any type.

There are a few 'correct' approaches to this depending on exactly how much you can spend:

• Look into getting some SATA Port Multipliers (essentially, these are like USB hubs for SATA devices). You will need support in the OS for this to work, but it's probably the least expensive option that's likely to be sufficiently reliable (just don't chain the port multipliers, it technically works but it causes serious performance issues in most cases).
• Just get a proper SAS HBA for the file server. SAS controllers work just fine with SATA disks (they have to) but are far more efficient than SATA controllers and usually have more ports (the small ones will typically have 8 ports). If doing this, put the server's OS on the SATA connectors on the MB. If you have to keep this as a specific system, this is what I would do.
• Get a dedicated NAS system. For a good one, you'd e looking at maybe 4-5 digits in terms of cost, but it would probably outlast whatever else you have, and would almost certainly scale well beyond what you actually need. FreeNAS is the OS I'd suggest here (iXsystems, the company backing FreeNAS, does reasonably priced semi-custom systems that are high-end enterprise quality). From there, you can either use iSCSI to expand the file server's storage, or you could just use the NAS directly.
• Buy a bunch of small inexpensive systems, throw a big storage device in each, and then set up a clustered filesystem. GlusterFS would be my specific recommendation here (as long as you don't need really fast storage, you can throw together individual GlusterFS nodes for under 500 USD each). This will give you the best long-term scalability (it can easily go into the thousands of TB range without issue provided your networking hardware is good), but puts significant limitations on other choices you might make about your infrastructure. I've done this before myself with both Intel NUC systems and Raspberry Pi's.
• Shell out probably hundreds of thousands on a proper SAN. Unless you're dealing with a big company, just don't, it's usually a waste.

The hub, as any USB device, is either "bus" or "self" powered.

Devices are enumerated normally, and come up in configuration 0, where no interfaces are implemented and power is limited to 100 mA.

The OS may only enable configurations with higher power requirements if the power budget allows.

A bus powered USB 1.1 or 2.0 hub asks for 500 mA for its working configuration, which is enough to give 100 mA each to itself and four downstream devices (which is why USB hubs always have four ports), and downstream devices are powered only when that request was granted.

A self powered USB hub asks for 4 mA, which is pretty much a symbolic value -- this configuration uses less power than the inactive configuration, so it is always inside the power budget. The hub must refuse the configuration switch if the power adapter is not connected.

Hubs offer both self-powered and bus-powered configurations, and the OS will try them in turn. If the power adapter is not present, the self-powered configuration is rejected, and the OS checks if the power budget is sufficient for a bus-powered configuration.

So, in a tree with an arbitrary number of hubs, there is either enough power for all devices, or there is a device for which the OS knows that the power budget does not allow activating a "working" configuration, which causes a message to be displayed in the UI.

A seven port USB 1.1 or 2.0 hub consists of two four port hubs, where one is downstream of the other, so insufficient power to that hub would leave four downstream ports completely unpowered, and the OS would request the user to plug in the hub's power supply.

With USB 3.0, the numbers change a bit because it is now possible to request more power, but the general idea remains the same: if the power budget doesn't allow it, devices will not be activated.

The hub is aware that the total power budget for its downstream ports is 2 A, and reports that fact to the OS. The OS will refuse to activate more disks than that budget allows, so expect only a few of the disks to spin up.

In theory, the disks could attempt to start without permission, which would be a violation of the USB specification. What happens then depends on whether the hub actively limits port power. I would not entrust data to any disk that does not wait to be explicitly switched into an active configuration.