My question was marked as a duplicate. How can I object?

Question

My question Backup with local manifest was marked as a dupe of Improve RSYNC scan speed / Alternate approach?. But it's not

The other question asks how a rsync scan can be sped up in general. The answer to the other question refers to a new rsync version where the file transfer can already start while the files are still be compared. I already use that version.

My question asks whether, after an rsync, I can somehow store a manifest/directory/whatever of my local==serverside files, to make the file list construction for the next backup a process that can happen entirely locally (without a network connection). I know that the backed up files won't change on the remote server, so this should be possible.

How can I object to the 'dupe' tag?

Answer 1

The best way to object to a question being marked as duplicate is to edit the question and explain clearly how the other question does not fit your situation. It's not sufficient to simply add a comment, as those are usually only seen by the people participating in the comments at that time.

Once you edit your question, it will automatically be placed in a review for reopening, where community members can vote whether to reopen it. It also will appear again on the home page, where everyone can see it.

Answer 2

I suppose that as one of those who voted to close it, there is some onus on me to respond.

Firstly, you should be aware that one criterion for closure is that the answer to your question is the answer to an existing question. The questions don't have to be the same, as long as the answer is a good fit.

I accept that, in this case, the answer isn't a good fit, because you're already doing it - but you didn't tell us that in your question. Yes, we could have elicited that by careful questioning in the comments, but the etiquette here is that the author of the question does the legwork, when writing the question, to show us what research has been done so far, what's already been considered, why it was inapplicable or how it didn't work, and so on.

I also note that you seem to have answered your own question: if you have a list of local files you want copied to a remote system, with no reference to any existing copies of the files on that remote system, then I, too, think tar is what you need. If you don't agree, clarifying why that's not the solution would also be necessary, because at the moment your question has a strong whiff of the XY problem about it.

If you edited your question to bring it up to these standards, I for one would vote to reopen it.

Answer 3

Since I was participating in the original Q&A with some comments and the first to vote too, I'll add my two cents as well.

I completely agree that the duplicate question is not quite the same as yours, but implied in your question is that you have performance problem with your rsync job, which you're trying to resolve.

The fact is that rsync version 2 is still widely in use (and your question didn't mention the version of rsync you'd been using). Therefore the duplicate answer in the linked question explains quite well the performance improvements made in rsync version 3 and the conditions that need to apply to actually benefit from them (which are relevant even when you already run version 3).

That for me was the reason to suggest that in fact it might be a duplicate Q&A.

Your comments clarified that a little but by then the peer review process can easily overlook those unless you edit/update your question.

Even re-reading reading the question now it still gives me the impression that it potentially is an XY problem where rather than solving the implied underlying performance problem you appeared to be asking about a non-standard work-around, effectively how to make rsync not act like rsync.

Rsync is of the "trust but verify" school of thought and if you don't want/need that you can still somewhat use the rsync protocol, which was what I focused on, but the alternative is to simply not use rsync, but for instance use actual back-up software and do incremental-forever backups.

And a final thought: a (single) replica is not often a substitute for a back-up.