The only two published recovery targets in our cloud DR set, read closely

What does each figure measure?

An RTO is how long a service may be down. An RPO is how much recent data or change may be lost. A tool can be quick to bring a service back and still lose an hour of data, or keep data loss to seconds and take a day to rebuild the surroundings. The two published figures in our set cover one each.

Where does Firefly's RTO appear?

Firefly's home page states an RTO under 1 hour alongside automated cross-region failover. Its disaster recovery page repeats the figure, and its pricing page lists Instant Recovery with an RTO under 1 hour as part of the Enterprise tier. That last detail matters for buyers: the figure is attached to the tier that is custom priced, not to the published Essential tier.

What the pages do not say is how the figure was measured: for what size of environment, which resource types, and whether it includes applying the generated Terraform. Firefly also publishes no RPO. Because it does not back up data contents, the data-loss window for databases and volumes depends on whichever data backup product you pair with it.

Where do Arpio's RPOs appear?

Arpio's pricing page puts an RPO on each tier: as low as 15 minutes in Standard and real-time in Premium. Its home page describes predictable, validated RTO and RPO and a 30-minute setup, but gives no RTO figure. The 30 minutes is a setup time, not a recovery time.

The tier link cuts both ways. It makes the figure concrete, and it means the real-time RPO is a Premium feature at $36k single-cloud or $54k multi-cloud a year, billed annually, for 50 core resources.

What about the others?

Commvault Cloud Rewind publishes no RTO or RPO; it states a 276X decrease in recovery time and a 99.9% cloud app resilience SLA, which are not recovery targets. Cohesity publishes none on the Cloud Rebuild pages we reviewed. Scalr, StackGuardian and Gambit Security have no recovery product of their own, so a recovery target would not apply. A missing figure is not evidence that a tool is slow; it is evidence that you will have to ask.

What should you ask before relying on a figure?

1. Which tier and which resources does the figure apply to?
2. Was it measured on a customer environment, a reference environment or calculated?
3. Does an RTO include the steps people take, such as approving and applying a rebuild, or only the tool's own work?
4. Does an RPO apply to configuration, to data, or to both?
5. Can we reproduce it in a proof of concept on one of our own applications?

Why do so few vendors publish a figure?

A recovery time depends on the customer's environment: how many resources, which services, how much data, how the network is built and how quickly people approve each step. Vendors who publish a single figure take on the risk that a customer's first test misses it. Vendors who publish none push the question into the sales process. Neither choice tells you how a tool will perform for you, which is why the useful step is to ask how a figure was produced and then reproduce it.

How should a published figure shape a shortlist?

Treat it as a starting point for the conversation, not a filter. A tool with no published figure may still meet your target, and a tool with one may meet it only in a higher tier. The figure is most useful when it comes with its conditions: tier, scope and method. If a vendor can give those in writing, you have something to test against.

How does this site use the figures?

Published recovery targets carry 10% of our weights, and Firefly and Arpio tie on that criterion at 7.0 because each publishes one of the two figures. The recovery time estimator compares your own RTO and RPO with the two published figures and labels each as a vendor claim. We did not measure either.