I would classify both of those as "moves", not "Copy", but besides that you're correct. The compiler needs to move the values around.
However, in Rust, moves (and usages of Copy) are guaranteed to always be a pure byte-for-byte copy and nothing else, so they're always very fast. (If you know C++, then you might think of Move constructors and Copy constructors - Rust has neither of these).
The compiler will usually optimize them all out, but even if it didn't, it would be almost instantaneous. Unless you're storing a ton of data in a struct (maybe 256+ bytes?) AND your code is a hot path in a loop, it's very rarely worth avoiding - trying to avoid moves of small structs like this is the kind of micro-optimization which is almost never worth anything.
If you do want to avoid copying the full data, then you can always surround the structure in a Box. It'll be moved onto the heap once, and then you'll just be copying around a ptr to the heap. But unless you have a ton of data and move it around a ton without accessing it, this will just make everything significantly slower.
It's also not the case that you can always avoid copying (even by optimization). If, for example, inlining didn't happen because there is a dynamic call through a function pointer, then the value cannot just be placed/instantiated directly at the address the function will want to move it to. Instead it has to go through the ABI-specific process for argument passing, which might include moving parts of a struct into registers, or pushing the entire thing on the stack before the call.
In general, just don't worry about moves. The optimizer will remove excess copying if it can, and you can't do any better if it's not possible.