Continuing with the restoration of your site would result in a broken site.
The URL of the site you are restoring to contains a part of the URL path of the site you backed up from. This will cause your restored site to fail.
For example, let's say the original site's URL was
http://localhost/foo. Note the foo bit? This is the URL path of the site you are
backing up from.
If you try to restore this to
https://foobar.example.com, or even
https://foobar.com the restored
site will fail. As you can see all these URLs have foo (whole or
partial) in the domain or subdomain of the site we are restoring
Because both original (backed up from) and restoration (restoring
to) URLs contain the common text
replacement of URLs and relative paths inside your site's database
.htaccess files will get mixed up.
This will cause your restored site to be broken and unusable.
This is not something that can be worked around automatically.
WordPress is storing both absolute and relative URLs. In the case of
relative URLs in our example, they are expressed by WordPress similar to
/foo/something. Since the restored site is in a different
path (in our example that's
/ i.e. the domain's root) we need
/. However, this would also
replace it in
https://foo.example.com turning it into
https://.example.com. Whoops! Now that link is broken!
You might think that's silly. Clearly, the https://foo.example.com URL is something that came from another replacement during restoration. Obviously running more replacements on top of what we have already replaced is wrong. Unfortunately, computers can't "mark" replaced text in any way, at least not without going into very complicated code which would have caused the data replacement to take so long that most servers would fail even for the tiniest sites. The only thing we can reasonably do is run all the replacements against the same content one after another. This is what is breaking the restored site.
It is recommended that you first try to restore to a location that does not share the same text in any part of its URL as the intended destination. Then you can back up this temporary restored site. Finally, you can restore that new backup to the intended destination.
In our example, we can take a backup from http://localhost/foo and restore it to http://localhost/temp123. Since foo and temp123 are very different we do not risk any issues with URL replacements. The restored site works.
Then, we can take a backup from http://localhost/temp123 and restore it to https://foo.example.com. Again, temp123 and foo.example.com are very different, therefore we do not risk any issues with URL replacements. The restored site works.
During restoration you end up in the Data Replacement page. There you can see all the replacements which will take place. Find all the replacements with just the path of the site and append a forward slash to them.
For example, replace FROM /foo TO / should become replace FROM /foo/ (notice the trailing slash) TO /.
In most cases this works without having to do a double restoration.