Does updating a user story in the sprint backlog need to update it in the product backlog?

It seems like this question is based on the assumption that an item in the Sprint Backlog is some kind of copy or clone of a Product Backlog Item. Although old versions of the Scrum Guide did differentiate between Sprint Backlog Items and Product Backlog Items, that hasn't been true for a while, but I'd have to see exactly when the wording was changed.

The November 2020 Scrum Guide says:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

I've interpreted this to mean that a Product Backlog Item that is selected for the Sprint is moved from the Product Backlog to the Sprint Backlog. The mechanics of this, along with how you go about decomposing the Product Backlog Items and create the actionable plan depend on the team and the tools they are using. The options available to the team vary depending on the representation of the Product Backlog and Sprint Backlog. Using sticky notes is different than using something like Jira, for example.

Typically, I try to encourage the team to have a well-refined top of the Product Backlog to minimize the amount of refinement that happens at Sprint Planning. However, things that happen at the Sprint Review could change the Product Backlog and some unrefined (or at least not fully refined) items may bubble up to the top or be added. The team may refine the items during the Sprint Planning, and the Scrum Guide acknowledges this when discussing how the team goes about selecting items from the Product Backlog for inclusion into the Sprint.

If there is refinement happening at Sprint Planning, I'd encourage the team to refine the items before selecting them for the Sprint. Of the Product Backlog Items that are created by decomposing or otherwise refining an existing Product Backlog Item, only a subset may be necessary to actually support the Sprint Goal or be important enough to include in the Sprint. Some of the items created may need further refinement or depend on receiving feedback from stakeholders before it makes sense to work on them.

The other case may be that you're in the middle of a Sprint and working on a selected Product Backlog Item, where you find that it's very large and it's possible to decompose the work. It may be a good idea to decompose the Product Backlog Item and put the newly created ones onto the Product Backlog. This helps the stakeholders looking at the Sprint Backlog understand exactly what the team is working on and allows discussions to begin about the importance, value, and ordering of the other Product Backlog Items that the team isn't actively working on. If the work is going to be done in the Sprint, though, I'm not sure that it makes sense to add Product Backlog Items, whatever that means to your team, to either backlog.

An item will remain in the Product Backlog until it is Done or otherwise retired from it. Planning the item into a Sprint Backlog does not therefore strictly "move" it out of the Product Backlog, even though we often use that language. The Sprint Backlog is perhaps better thought of as providing transparency over selected items in the Product Backlog and the forecast of work needed to meet the Sprint Goal.

I have always seen the Product Backlog as a large To-Do list and the Sprint Backlog as a sublist of the ones that will be worked on.  They aren't two different things. 

Using the To-Do list example, consider that you have a long list of items that your significant other wants you to do around the house (in the US this is affectionately known as a Honey-do list because it is things that usually are communicated by "Honey, do the ...").   I will look at that list and determine what I can get done over the weekend.  I do those things and check it off the list.  I don't create a new list for my weekend chores. If I need to separate the "do the lawn" into "mow the lawn, plant new flowers, trim the hedges, fertilize, put down mulch" and not all of that can be done in the same weekend, then I do it on the main list. That way the main list will always contain a list of items that need to be done. I will try my best to break larger tasks into smaller ones before I start doing the work because it makes it much easier for me to determine how much of the work I can get done.

Many Thanks for you

Really, you helped me

There is not a particular rule on how to specifically manage the relation that exists between product backlog and sprint backlog. So instead of looking for the “best practice”, it would maybe be better to consider the pros and cons of what you are issuing:

 - Choosing one option over the other will actually bring more transparency to the process?

 - Which option is simpler? Is there a risk that one option would add the waste of “over processing”? 

- Which option will bring easier information maintenance?