If this is only one message, this is a problem, why not write it to a file (and clear the file) before processing the message. After confirming the message, delete the file.
And if you are concerned about the failure of the message broker, the first step is to upgrade it to RabbitMQ 2.4.1, which runs on Erlang R14B02. The second step is to group it so that you have several servers acting as MQ brokers. And only then change the application to track processed messages either by time stamp or by saving message identifiers. Then, if RabbitMQ requests a message, you will already have it, and it will process it and remember it. When this happens a second time, you will ignore it.
You may need to set the prefetch to 0 for this to work correctly.
And there is another alternative. You might consider writing your own RabbitMQ plugin to provide the exact behavior you need. Erlang may look complicated at first sight, but it’s actually not so difficult to learn from an experienced programmer who has already learned several languages. In particular, if you have someone with functional programming in languages such as Haskell or CAML, they will quickly pick up enough Erlang to do the job.
Due to the internal Erlang message processing model, RabbitMQ plugins can essentially do whatever they want. There is no specific limited plugin API to which they must conform.
In other words, if RabbitMQ does only 99% of what you need, consider yourself lucky that with a little work you can use it 99% and achieve everything you need. But for this you need to get away from the idea that RabbitMQ is another package that you install using the installation tools of your system package. In cases like your RabbitMQ, you should be seen as a critical tool, and you should install Erlang and RabbitMQ from the source and customize them according to your needs, not allowing your OS to limit you.