Restore not possible

[sponch]

Had some troubles with Nextcloud and now wanted to restore from backup.
Tried different backups from Hetzner Storagebox (cifs) all with the error:
Crypto Error: Invalid password or tampered file (mac mismatch)
Haven't changed any encrypting passwords (at least I don't know about it).

..edit: just hung in the storagebox some days ago as I always had some backup errors..but help me - even If there should be another encryption password - as long as it is in the Backup options it should use the one for restore, right?
edit2: cloning doenst work as well (same error)

[jdaviescoates]

I can't help, but just to say this stuff is part of why I tend not to use encryption as in my limited experience the risk of my locking myself out of my own data is higher than the risk that someone else will access it!

[james]

Hello @sponch
Can you please try to manually decrypt a singular backup following this guide:
https://docs.cloudron.io/guides/decrypt-backups/

[sponch]

TypeError: Invalid initialization vector
    at Decipheriv.createCipherBase (node:internal/crypto/cipher:117:19)
    at Decipheriv.createCipherWithIV (node:internal/crypto/cipher:128:3)
    at new Decipheriv (node:internal/crypto/cipher:247:3)
    at Object.createDecipheriv (node:crypto:145:10)
    at decryptFilePath (/opt/homebrew/lib/node_modules/cloudron/src/backup-tools.js:55:36)
    at Command.decryptDir (/opt/homebrew/lib/node_modules/cloudron/src/backup-tools.js:284:50)
    at Command.listener [as _actionHandler] (/opt/homebrew/lib/node_modules/cloudron/node_modules/commander/lib/command.js:552:17)
    at /opt/homebrew/lib/node_modules/cloudron/node_modules/commander/lib/command.js:1586:14
    at Command._chainOrCall (/opt/homebrew/lib/node_modules/cloudron/node_modules/commander/lib/command.js:1470:12)
    at Command._parseCommand (/opt/homebrew/lib/node_modules/cloudron/node_modules/commander/lib/command.js:1585:27) {
  code: 'ERR_CRYPTO_INVALID_IV'

[james]

Is this a tgz or rsync backup?

[sponch]

@james rsync

[james]

@sponch
Once, I've seen a strange error with rsync type backup where a zero byte file blocked the whole process.
Because, a zero byte file does not even include the encryption header needed for the file.

Can you please run the following command for the failing rsync decryption:

find . -type f -size 0

If you find any zero byte files, move them somewhere else outside the folder and try the decryption again.

[sponch]

a run the command in the encrypted backup directly right? doesn't find anything

[sponch]

what would you recommend: rsync or tgz for future backups?

[p44]

We discussed this issue here:
https://forum.cloudron.io/topic/12632/tarextract-pipeline-error-invalid-tar-header/24

I've encountered this problem twice...

@sponch I have a question: Were the backups you're trying to restore still in their original location (where they were first created), or had they been moved/copied to a different Hetzner Box before restoring?

I’m asking because the files I tried to recover (unsuccessfully) had been transferred between Hetzner Boxes, and I’m wondering if that could be the root of the issue.

Edit: Were the files you tried to restore from the Hetzner Box originally created by the same specific Cloudron instance? Or were they from a different instance (e.g., after a reinstall)? I’m asking to help trace the root cause of the issue.

@james I believe that in some cases encryption is necessary, so increased security inherently comes with the trade-off of being locked out of the recovery process. However, in this specific case, we should investigate the root cause of the issue, since it seems that has affected multiple users...

@sponch @james Another hypothesis that comes to mind is the use of special characters in the password, which might not be interpreted correctly during the backup recovery process – Eg. a Gui problem –. I’ve since updated my passwords to only include uppercase letters, lowercase letters, and numbers (40 characters long), and the issue appears to be resolved... but this is only an hypothesis.

[sponch]

@sponch I have a question: Were the backups you're trying to restore still in their original location (where they were first created), or had they been moved/copied to a different Hetzner Box before restoring?

Same location (only the prefixed changed months ago - should not concern the recent backups)

I’m asking because the files I tried to recover (unsuccessfully) had been transferred between Hetzner Boxes, and I’m wondering if that could be the root of the issue.

Edit: Were the files you tried to restore from the Hetzner Box originally created by the same specific Cloudron instance? Or were they from a different instance (e.g., after a reinstall)? I’m asking to help trace the root cause of the issue.

Same instance. Nextcloud is backed up daily. Last fews days restoring always ends up with same error.

@sponch @james Another hypothesis that comes to mind is the use of special characters in the password, which might not be interpreted correctly during the backup recovery process – Eg. a Gui problem

Just restored another (unimportant) app from same backup day. Worked perfectly.

[p44]

@sponch ok thanks for informations. I hope those informations could help to reproduce issue and eventually find the source cause...

[sponch]

hi and thanks four you information. Unfortunately I could find the cause.... and set up a new Nextcloud instance (only had 5 users and offline data from the clients).
As other apps could be restored w/o any problems it must have been s.th. related to Nextcloud specific restoration I guess.
Just made a clone of the new Nextcloud App (encryption disabled....)worked perfectly.

[p44]

@sponch you disabled Cloudron Backup Encryption or Nextcloud App Encription?