Duplicacy now uses a new format for the config file which can't be read by Vertical Backup. Once again, any help is much appreciated! VB just doesn't like storage-B for some reason. I can also, with Vertical Backup, initialise/reconnect to storage-A from host-B across the internet. vmx files (as a simple test) from storage B, using Duplicacy. What makes me think this is a Vertical Backup issue is I can initialise and restore one of the VMs'.
Duplicacy change encryption password password#
But I've also tried pasting the storage password from my password manager directly into the PuTTY terminal. Just to throw a spanner in the works, my passwords are completely random and the one for storage-B has a backslash in it, which I've escaped with double-backslash in the json-format 'password' file. I'm currently successfully running the backup on host-A to storage-A and also copying from storage-A and storage-B is now working. Host-A -> storage-A -> -> storage-B -> host-Bīoth storages are copy-compatible but use a different password for encryption (I didn't use -bit-identical either, which is intentional). The downloaded file 'config' is either corrupted or not encryptedīasically I'm trying to run a test restore on the 'copied' storage that I'm now syncing across the internet from the original host. Storage set to the password to encrypt/decrypt the storage: Running init command - chunk size: 1048576, encrypt: True, temporary directory: None vertical -v init -encrypt cert-esxi6 Backup 1.2.0 Cheers.Ĭontinuing on from my experiments, and although I could be doing something wrong, it seems Vertical Backup isn't able to decrypt a copy-compatible storage that's been copied from the original with 'duplicacy copy'. I'll also test duplicacy -copy after the first VM in case I run into further problems (although I don't expect to). I think, since my storage has only 3 VMs and a handful of revisions, and that the new hashing function is the future(?) and the default now, I'll just reinitialise to a fresh storage. This environment variable was added by this commit to fix this compatibility issue. If you need to work with an existing storage, you can build the latest version of Duplicacy from the github master branch, and set the environment variable DUPLICACY_DECRYPT_WITH_HMACSHA256 to 1 before running Duplicacy. The storage must be initialized with this build for the fix to work. This is a bug caused by a mistake in Vertical Backup using a different hash to derive the encryption key. Running Vertical Backup v1.2.0 (the memory efficient version posted here) and Duplicacy v2.1.0. Why would Duplicacy not be able to read the encrypted snapshots? I mean, it seems to be able to read the encrypted config file from the storage using the supplied master password. It's my understanding that Vertical Backup and Duplicacy should be directly compatible. I'm 99.999% sure the storage isn't corrupt in any way, nor should there be permissions issues (I ran Command Prompt as Administrator, just to be sure). I also tried to initialise the dummy storage with the original URL, but I get the same error. Id: revisions:, tag:, showFiles: false, showChunks: falseį:\verticalbackup is the path to the Windows/cygwin SSHD storage for Vertical Backup. New options for storage F:\verticalbackup have been savedĮnter storage password:*********************************įailed to decrypt the file cipher: message authentication failed The storage 'F:\verticalbackup' has already been initializedį:\dummy will be backed up to F:\verticalbackup with id from-dummy
Using a static salt and 16384 iterations for key derivation
Reading the environment variable DUPLICACY_PASSWORDĮnter storage password for F:\verticalbackup:********************************* But then I ran into some issues with the encryption:į:\dummy>duplicacy -d init -encrypt from-dummy "F:\verticalbackup" Now I'm planning to use the duplicacy -copy command to sync backups off-site via SFTP, but first I want to 'seed' the initial copy by attaching a new storage locally. I've succeeded in getting some backups running now and things looks quite promising in my trialling of Vertical Backup the incremental backups are going pretty fast thanks to the de-duplication.
0 kommentar(er)
