diff --git a/doc/tips/Recovering_from_corrupted_encrypted_GITBUNDLE_file.mdwn b/doc/tips/Recovering_from_corrupted_encrypted_GITBUNDLE_file.mdwn
new file mode 100644
index 0000000000..d3d175b0af
--- /dev/null
+++ b/doc/tips/Recovering_from_corrupted_encrypted_GITBUNDLE_file.mdwn
@@ -0,0 +1,63 @@
+Yesterday upon setting up an `hybrid` encrypted rsync backend (with `git-remote-annex`) support, I stumbled around this bug. The annex remote would corrupt itself and no amount of `git annex repair` would fix it, unfortunately.
+
+```
+$ git annex push
+push <remote> 
+Full remote url: annex::<remote-uuid>?encryption=hybrid&rsyncurl=<url>&type=rsync
+gpg: zlib inflate problem: invalid block type
+  user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","13","--decrypt"] exited 2)
+git-annex: Failed to download GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
+Full remote url: annex::<remote-uuid>?encryption=hybrid&rsyncurl=<url>&type=rsync
+gpg: zlib inflate problem: invalid block type
+  user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","13","--decrypt"] exited 2)
+git-annex: Failed to download GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
+
+  Pushing to <remote> failed.
+failed
+push: 1 failed
+```
+
+I then started to investigate the temporary files in `.git/annex/tmp` and found the aforementionned **GITBUNDLE**, as well as it's encrypted counterpart.
+
+```
+$ tree .git/annex/tmp/
+.git/annex/tmp/
+├── GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
+└── GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839
+```
+
+I wanted to confirm that the file was corrupted for real, so obtained the cipher for my hyrid repository like so:
+
+```
+$ cipher=$(git show git-annex:remote.log | grep 'name=<remote>' | grep -oP 'cipher\=.*? ' | sed 's/cipher=//')
+```
+
+And confirmed the encrypted file was indeed corrupted by decrypting it manually:
+
+```
+$ echo $cipher | base64 -d | gpg -d | tail -c +257 | gpg --batch --passphrase-fd 0 --decrypt .git/annex/tmp/GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839 > /dev/null
+gpg: encrypted with rsa2048 key, ID <gpg-id>, created 1970-01-01
+      "... <...>"
+gpg: encrypted with cv25519 key, ID <gpg-id>, created 1970-01-01
+      "... <...>"
+gpg: AES256.CFB encrypted data
+gpg: encrypted with 1 passphrase
+gpg: zlib inflate problem: invalid block type
+```
+
+I then searched in the annex's directory for the uncorrupted **GITBUNDLE** to find out that it indeed existed:
+
+```
+$ find . -type f -name "GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49"
+./.git/annex/objects/Vg/Mm/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
+```
+
+Now that I have a way to get the symmetric cipher and the source file, as well as it's encrypted filename, I can re-encrypt it:
+
+```
+$ echo $cipher | base64 -d | gpg -d | tail -c +257 | gpg --batch --passphrase-fd 0 --output /tmp/GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839 --symmetric ./.git/annex/objects/Vg/Mm/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
+```
+
+And then upload it to replace the corruped one on the remote.
+
+I then confirmed it was fixed by issuing a `git annex sync --content`.