The main purpose of best practices like DRY is not to make things easier for you, but to make things easier for future you(and for other people who'll work on the project). They care less about the process of coding and more about the final result. Of course, that doesn't mean the process is not important - but that's a concern for development methodologies and business planning(which you also need to balance)
In that regard, rewriting the logic for the server doesn't violate DRY - what could violate DRY is keeping both client and server side implementations and using them both. The rewriting itself creates work for you, but if once it's done you end up with a better application it can be worthwhile. Keeping both versions means you have to keep them in sync(changes to one must be replicated in the other), which makes the project harder to maintain. It's a problem for future you.
Now, like ddyer said in the other answer - if you send that data from the client to the server the server needs to validate it. So the main question is:
How complex is the to validate the progress compared to the calculating the progress?
If validating the progress is as complex as calculating it, you'll have to keep them in sync, which makes the project harder to maintain. It's different than having to syncing the two calculation implementations(Easier because bugs will pop earlier when validation code rejects progress that should be OK. Harder because there is no longer almost-one-to-one mapping between the logics), but it's still a problem for future you.
On the other hand, if validating the progress is much simpler than calculating it, you might consider calculating in the client side and sending to the server side. You should, of course, take into account things like:
- Is the progress calculation requires lots of client/user interaction? If the server for example, will have to contact the client to ask the users questions, and needs these answers before the user can proceed, all this ping-pong can be prevented if the calculations are done client-side.
- If the progress calculation is mainly for displaying it to the user, and you only need it at server side for logging purposes, it can be easier and produce better results for the client to do the calculation itself instead of having the query the server each time it wants to update the progress display.
- How much work is it to reimplement the logic compared to implementing the API for transferring it between client and server?
- Do you want to allow third party clients? If so, if the logic is at client-side they'll need to reimplement it...
And so on - the point is these should be considered only if the validation logic is simple(which means you can probably do many changes to the calculation logic without having to change the validation logic), since having to sync complex validation logic with complex calculation logic will make the project harder to maintain.