Kenkendk wrote about some problems with 7z. So now I have already backed up lots of stuff with 7z. I do not want to delete anything and re-backup. Should I do it? Or can I change the backup set option and then get a mixed backup which slowly converts to zip over time…? Is that possible?
This task: It’s almost impossible. I deleted the backup folder on Google drive. I started backup: does not upload anything. I deleted+repaired database: it tells me “No files were found at the remote location, perhaps the target url is incorrect?”
Do I really have to export configuration, delete config, import configuration?
I’ve done this a couple of times (wanted to change folder names in B2 which is impossible) – it just takes a lot of trying between deleting data & repairing & trying something else when that doesn’t work. The fastest way, if you’re deleting and starting over anyway, might just be to export your config and re-import using your new preferred parameters.
Also: it sounds like it might already be too late, but what I was originally going to suggest was to change your volume size to something a bit bigger and then run “compact now”. From what I’ve seen, that might download, re-pack, and re-upload every data volume in your archive if you let it (and should be fine if you don’t have to worry about download bandwidth… not suggested on B2 unless you really really need it… should be fine on GDrive though).
in any way that I could find. At least not via the web interface.
When I did my first B2 test run, I dumped the files straight into a bucket without putting them into a folder - I quickly regretted that, but there was no way to fix it directly. I had to delete, create a folder with a “temp” name (mistake), then re-run my backup. Then when I wanted to move away from the “temp” name on that folder… oops, can’t rename folders. Had to re-do again. The good news is that it’s all done now, no harm no foul.
If the uploaded 7z files are verified (after a compact command is run, if auto-compact is enabled), wouldn’t this be okay? E.g. all new files/blocks uploaded would be .zip, and the old 7z files were not corrupted?
However, is there actually a way to verify all files currently? As I understand it, the verify files option just checks that the already encrypted blocks exist and match hashes, not the actual contents, so it wouldn’t be helpful. How about repairing / recreating the database - would that expose any corruption? Or Would the only way to truly verify files is to somehow attempt restoring at least one file out of every block?
If one REALLY wanted to change compression settings (such as 7z vs zip) of existing files, would it work to fiddle --small-file-size, --small-file-max-count and possibly --threshold such that every file would be considered small so would be downloaded, re-compressed with the new settings, then re-uploaded?