Backup via rsync seems sort of broken

@gnite, i had several issues

  1. I use port 2345 for SSH as I cannot use port 22, I have a config file for ssh and use the port option for the host, this is working fine for the initial installation / configuration cause all is accepted and working, but it will fail further in the process as the -p 22 is still used and not port 2345, ok no problem, I can change backup.py
    cause in all other way I get an error on public key, so it tries port 22 … bummer not using the config file (but no idea why not)

Finally I was able to run sudo management/backup.py --full and yes… data !!! … but …
indeed only 4K files …
no idea why no other files are rsynced.

Try commenting out the first line of rsync_ssh_options array in backup.py, line 18.

rsync_ssh_options = [
“–ssh-options=’-i /root/.ssh/id_rsa_miab’”,

to:

rsync_ssh_options = [
# “–ssh-options=’-i /root/.ssh/id_rsa_miab’”,

I’m pretty sure you will have to delete or move the backup-files already in your destination before running backup.py again. I don’t think you need --full as it wont find any full backups anyway.

2 Likes

can try that of course :wink: but no idea if it will solve it

first line commented out … and damn … here it is …
but only full indeed … but also probably not a good packed backup. as the info is about a full backup in a folder where the key is visable

Odd, my “fix” solved my issue with only full backups, but I still can’t list any backups. I’m using rsync as destination, normal ssh port tcp/22. As I mentioned, I had to delete my old backups for anything to happen.

Anyway, very odd.

with 0.30 I had to reboot my server before the files where visible.
No idea why I do see the content now :wink: (yeah I rebooted several times yesterday) :wink:


Dude, thanks! :smiley:

This did seem to fix it, thanks :+1:. Though I’m kind of curious how nobody, me included obviously, caught on that those “4K"files” were, in fact, directories :roll_eyes:.

1 Like

I assume you attempted to do systemctl restart mailinabox to have it do it’s startup bits?

no never tried that :wink:
my box has a few users (5) and if someone complains I will tell them to look for another mailserver :wink:
uptime is no issue for me.

but did someone try to restore it to a place yet?

update:
@durd I have removed my other backups and have mailinabox created a new full backup. Want to see what will happen tonight if there is or will be a diff backup .

Than I will try to unpack the files on my home NAS … to see if I actually get my content back :wink:

Oh, so you haven’t been able to restore your backups from v0.30 to v0.40?
I was able to do so, it was first after the upgrade I got to be having the issues with rsync backups.

@durd, I was able to restore from 0.30 to 0.40 but I wonder if the backups of 0.40 are valid :wink:
I was very pleased with the way the upgrade from 0.30 to 0.40 went after I got access to my newly installed machine again

Chicken - egg: DigitalOcean sends password of box to my mail … oh oh … yeah … that machine i accidently removed (after all the backups etc… ) but before the new machine was made …

Ah, I understand; No, I haven’t tried restoring my new v0.40 backups. I’m betting on the issues being fixed properly before I have to restore anything :slight_smile:
I’m also just relaying emails via MIAB, none are stored there for more than 20mins, unless it’s in Junk.

i will test this weekend a restore on a spare VM to see if it can be unpacked …
did that before I restored 0.30 to 0.40 to be 100% sure my backups were valid :wink:

1 Like

w00t …

seems that it works at my site now as well after I removed the manually made backups

1 Like

@durd I tested the rsync feature with also the duplicity unpack method with secret key.

Where rsync first created folders, after removing and altering the backup.py now all files are created accordingly and I am able to restore the data

puffer:/srv/dev-disk-by-label-PufferBackup/Backup_Mail# sudo -E duplicity restore --force file:///srv/dev-disk-by-label-PufferBackup/Backup_Mail /home/testmailserver
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Thu Jan 24 03:00:06 2019

data will be unpacked now.
including incremental stuff

Kool, sounds great :slight_smile:

Yesterday setup rsync for the first time and was wondering why there are no listed backups in the admin backup-status page and there were folders synced instead of files. After I commented out the line you mentioned it’s working now! Thanks!

I hope it will be changed in the main install soon.

1 Like

Commenting out that line breaks backup for me:

Attempt 1 failed. BackendException: File /tmp/duplicity-ZNKYnk-tempdir/mktemp-oRd6Y4-2 not found locally after get from backend
Attempt 2 failed. BackendException: File /tmp/duplicity-ZNKYnk-tempdir/mktemp-oRd6Y4-2 not found locally after get from backend
Attempt 3 failed. BackendException: File /tmp/duplicity-ZNKYnk-tempdir/mktemp-oRd6Y4-2 not found locally after get from backend
Attempt 4 failed. BackendException: File /tmp/duplicity-ZNKYnk-tempdir/mktemp-oRd6Y4-2 not found locally after get from backend