The problem with these requirements is that what you're describing is quite impossible for a program to figure out in the case of arbitrary data being backed up. That's why it would be helpful to know your actual use case, not just your current conclusion on what you think the requirements should be.
Whatever you PUT onto the server, even if you force-overwrite remote data, is not certain to be the only data you have in that directory/on the server, as soon as any other device can theoretically also write data to it. If you don't care about any other documents in the same directory (a.k.a. sync the entire situation, not just what you have locally), then your restore will not be done with what you manually backed up, but with what you force-pushed plus whatever else was on there.
The only way (that I can currently see) to safely create a one-off backup with 100% only the data you have locally on that device, is to also manually manage a specific directory it is created in. You could copy your documents to that namespace and then simply enable caching for it. And when you want to restore, you could select that namespace/directory and also just sync whatever is in there back.
However, it's not really possible to recommend a good approach to you, without knowing anything else about the use case, like for example what kind of data is being backed up, how many documents, what average document size, and so on.
Edit: the important bit of API for what I suggested so far is that you can enable and disable caching for specific subdirectories on the fly from your app: https://remotestoragejs.readthedocs.io/en/latest/js-api/caching.html#list-of-functions
So what you can do is for example copy all documents to something like
my-category/backups/2018-03-13/, then enable caching for that and sync it to the server. And for a restore, you could let a user choose from your list of backup subdirectories and then do the same, but this time the sync would retrieve it from the server.