Unfortunately can’t, my provider doesn’t support shrinking the hard drive on VPSes. Otherwise I would just increase the disk space now and do an ordinary backup.
Bump? Is rsync ok then? Will I need more flags maybe?
I don’t know half of the flags you used, lol …
But I am confused. Why are you stating that your provider doesn’t support shrinking the hard drive?
You need MORE space, not less.
He’s basically saying that if he increases the space from the VPS provider then he will never be able to shrink it as they don’t support shrinking of space and he doesn’t want to spend the money having more space that he doesn’t need (after the upgrade is complete).
1 Like
So basically you’re saying that he says that he never keeps backups – I see.
I won’t go into the discussion of how potentially dangerous that could be.
@Dronfulj I’d use the flags -avz.
1 Like
I suppose its possible that he is doing some type of Snapshot backup rather then the built in MiaB backup.
Ill be honest, I use a snapshot like backup myself. I dont think that I would really use duplicity backup’s built into MiaB when I move from 18.04 to 22.04. I tend to think that there’s some work to be done before I can really move to the 22.04 v60 anyways.
Yeah, that’s the problem (I’m on Vultr). I put some large files on Nextcloud temporarily last month and I don’t have the space to do the duplicity backup right now, but I don’t want to run out of date software either.
If I do the duplicity backup I have to grow the instance (and pay for the extra space) and then again move to a new instance when I want to shrink the space again. Otherwise I have to remove the files and then reupload them and set again all the shares/permissions.
That’s why I just want to manually download/upload everything that the backup process would usually get.
I’m a bit worried about permissions as -avz doesn’t seem to catch permissions. I tried with --fake-super but I’m not sure if that worked since all files have my own local user and group instead of root:root or whatever.
Does Vultr allow you to restore from a snapshot? If they do then this is what I’d do. I would make a snapshot of your VM, then spin up a larger VM with that snapshot so you can do the backup on it.
I can forsee though that if these are media (not easily compressed) files that you may still have issues when you go to restore … but hey, it was an idea and maybe there is some part of it that you can run with.
1 Like
After (successfully) migrating my server from 18.04 to 22.04, I started getting the following status message when the server attempted to run its daily backup:
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====
This thread is a top search result for this error message, so I thought I’d follow up here.
Basically it turned out the problem was that I was using the same S3 bucket for the backups for my 22.04 server as I had used for backups for my 18.04 server, and the 22.04 server was trying to append the 18.04 server’s backups with its own (new and different) secret key.
While I suppose I could have started a new set of backups from scratch, what I did instead was I renamed the (new) secret key on my 22.04 server:
box@<newserver>:~$ sudo mv /home/user-data/backup/secret_key.txt /home/user-data/backup/secret_key-broken.txt
then copied the (old) secret key from my 18.04 server to /home/user-data/backup/secret_key.txt on my 22.04 server in its place.
After doing this I ran the backup command:
box@<newserver>:~$ export PASSPHRASE=$(sudo cat /home/user-data/backup/secret_key.txt)
box@<newserver>:~$ sudo mailinabox/management/backup.py
and it completed without any errors.