After upgrading to 0.40, which went pretty smoothly, i found that MIAB can now save remote backups via rsync, for which I have previously been using my own script. So I tried it and it kinda works but not really, it connects to thew remote server just fine but it only saves a bunch of files 4096 bytes in size each (https://i.imgur.com/viDZRhN.png), and in the admin panel the list of backups remains empty. That means the connection is good and permissions are good. Switching to local backups saves them properly. A manual execution of backup.py didn’t show any errors. Oh and the backup folder was empty to begin with, I didn’t reuse the one from 14.04. Any ideas?
1 Like
I have the exact same issue here. But I restored from the 14.04 backup and hoped/thought that miab would be able to continue working on top of the old backup.
I’ve looked around, but was not able to find a solution. Only two similar issues on github and this post.
If anyone has an idea what I could do to dig deeper here, please let me know!
Same problem here too. Actually didn’t notice until I found this forum-post.
I first had the issue that I could not lookup hostname, but that issue was related to the port
I added a config to the ssh config in MIAB so that there the port is used when the hostname is used
Working fine, I cannot login
But no feedback from the remote host that there are in deed already some backup files
as I restored from backup it should be able to see those, if not, no issue, but no mention that I can actually backup.
Just noticed that full-backup sized files are transferred and counted in size, but not listed in the MIAB-admin page:
<user>@<host>:<backup-path>$ ls -lah duplicity-full.20190120T215612Z.vol1.difftar.gpg/
total 251M
drwxr-xr-x 2 <user> <group> 4.0K Jan 20 22:57 .
drwx------ 42 <user> <group> 20K Jan 20 22:57 ..
-rw------- 1 <user> <group> 1.7K Jan 20 22:56 id_rsa_miab
-rw------- 1 <user> <group> 251M Jan 20 22:57 mktemp-HRLaB3-2
The backup location currently contains the backups listed below. The total size of the backups is currently 3.3 GB.
When Type Size Deleted in…
No backups have been made yet.
Running backup.py --verify produces below:
*snip*
Last full backup date: none
Using temporary directory /tmp/duplicity-uypTEW-tempdir
Traceback (innermost last):
File "/usr/bin/duplicity", line 1555, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1541, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1393, in main
do_backup(action)
File "/usr/bin/duplicity", line 1474, in do_backup
verify(col_stats)
File "/usr/bin/duplicity", line 866, in verify
collated = diffdir.collate2iters(restore_get_patched_rop_iter(col_stats),
File "/usr/bin/duplicity", line 750, in restore_get_patched_rop_iter
backup_chain = col_stats.get_backup_chain_at_time(time)
File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 974, in get_backup_chain_at_time
raise CollectionsError("No backup chains found")
CollectionsError: No backup chains found
Traceback (most recent call last):
File "mailinabox/management/backup.py", line 532, in <module>
run_duplicity_verification()
File "mailinabox/management/backup.py", line 350, in run_duplicity_verification
] + rsync_ssh_options, get_env(env))
File "/home/toe/mailinabox/management/utils.py", line 123, in shell
ret = getattr(subprocess, method)(cmd_args, **kwargs)
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
*snip*
Edit: that is i noticed the rsynced .gpg-files where in fact directories and checked them out.
Edit2: a full backup is transferred every night, or everytime backu.py is run. Can be quite expensive for some…
rsync normally does incremental backups copies … though I have not checked to see if the implementation in MiaB is set up properly - though I would assume it is … have you confirmed this to indeed be the case?
Edited to correct an incorrect word.
1 Like
*copies 
rsync - a fast, versatile, remote (and local) file-copying tool
Source: Ubuntu Manpage: rsync - a fast, versatile, remote (and local) file-copying tool
Edit: insert little giggle here
1 Like
Well, it’s not rsync that creates the backups, its Duplicity, which in turn just uses rsync to copy files around 
Either way, I can confirm it’s not incremental but full backups when run manually and when let run automatically over night. Unless the automatic or manual does not follow the normal backup method. I’m doubtful about that though.
I found something similar here, though super old. I don’t know much about Duplicity or how it works, but from what I can see there are no files cached.
Edit:
Found the big culprit, created a pull request here.
What’s left is getting the listing in the webgui working.
After the patch I deleted all the backups on the destination and reran backup.py twice. First it created a full backup, and the second time an incremental one.
Edit2:
–verify is still broken as I’ve mentioned in the PR.
1 Like
@gnite, i had several issues
- 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 
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 (yeah I rebooted several times yesterday)
This did seem to fix it, thanks 
. Though I’m kind of curious how nobody, me included obviously, caught on that those “4K"files” were, in fact, directories 
.
1 Like
I assume you attempted to do systemctl restart mailinabox to have it do it’s startup bits?
no never tried that
my box has a few users (5) and if someone complains I will tell them to look for another mailserver
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
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.