Is there a way to create a sandbox from the scratch org?

No, no, and no.

Scratch orgs are purposefully time-limited, and sandboxes can only be created and managed from a paid (production) org.

It sounds to me like you're mis-using scratch orgs here, like you're trying to force a square peg through a round hole. In my mind, scratch orgs are mostly meant for things like quick demonstrations and single projects that don't have any (or many) dependencies.

Needing to go through a laborious setup process each time doesn't sound like an independent (or single) project. I think that you should be using a developer sandbox instead of a scratch org.

• Sandboxes are not time-limited
• You can make a template for sandboxes (which may or may not reduce the amount of configuration you need to do, only available to use in partial copy and full copy sandboxes)
• Developer Sandboxes can be refreshed daily, if needed (though you'd need to go through your setup after refreshing a sandbox)
• Sandboxes allow you to specify an Apex class to be run after the refresh

You might be able to get away with using sfdx force:data:tree:import, but again, this really doesn't sound like a scratch org is appropriate in your situation.

The answer to all of these questions is no. Setting up a scratch org can almost always be fully automated, including loading metadata, data, and various settings. If it takes more than, say, 30 minutes or so, to spin up a scratch org, you're probably better off just using Sandboxes. Enable the new Source Tracking for Sandboxes feature, and you can use Sandboxes with all the upsides of Scratch Orgs, without the downside of a 30-day time limit. You can clone any Sandbox from any other Sandbox, but you cannot clone Scratch Orgs from a Sandbox or a Sandbox from a Scratch Org.

The other answers are both correct in pointing out that using scratch orgs requires you to think a bit differently about how you handle environments. As sfdcfox said, it's absolutely possible to automate everything that goes into a scratch org.

You're encountering a long time guiding principle of mine... Seaver's Law of Software Engineering:

Persistence means always having to say you're sorry

That wasn't created specifically for Salesforce but is rooted in similar concepts. If you are developing code that relies on declarative configuration in an instance that's not automated in version control, the mismatch in state due to lack of automation will always come back to bite you.

I used scratch orgs for years before I had the realization that "scratch" isn't intended to mean a scratch piece of paper you doodle ideas on. It's best thought of a "starting from scratch". Using scratch orgs effectively requires investing in automating the entire process of setting up a fully usable org. The value of scratch orgs is that you can start everything you do from scratch and test the entire process of delivering your product. The predictability and scalability is well worth the effort to create the needed automation.

We ran all our dev orgs as 7 day scratch orgs by default. Whenever someone came to me requesting a longer duration, I saw that as a red flag pointing to tech debt of missing automation to create a usable environment. It was absolutely the exception for us to create 30 day scratch orgs.

In my time at Salesforce.org, we developed a new model for development called the Product Delivery Model. The Product Delivery Model defines a product as a set of automation configurations in version control that can be run through a portable pipeline to deliver fully usable product experiences into an org. Automation is part of the product, not an afterthought and missing automation is treated as tech debt.

Ultimately, it comes down to a simple question. What is the source of truth for your product? Is it an org or is it version control? In order for it to be version control, you have to have everything defined in version control including all the post-install steps you do manually today.

I'm incredibly excited about Scratch Org Snapshots for what they can do to enhance a development process that properly uses scratch orgs as ephemeral environments to start from scratch to test your ability to deliver a product. Yet, I'm quite frightened that snapshots will become a shortcut that teams use to avoid properly investing in automation. Snapshots come from an org. If you did any manual setup in that org, then that org is your source of truth rather than version control.

As for how to actually do this, there are many options ranging from using sfdx and bash scripts to using automation frameworks such as CumulusCI (disclaimer: I used to lead the team that built CumulusCI at Salesforce.org but am really trying to keep this answer about concepts vs tools).