6 days ago, started getting this error when running the diff backups:
Ran backup.py manually, but get same error, no explanation. Doesn’t seem to be any logs anywhere with more info.
MIAB version v0.30 on Ubuntu 14.04.6 LTS. We’re getting ready to migrate to v0.41, but naturally need the backups to be working first.
Additionally, on the web GUI backup status page, loading just gives the time error in my last post and the Available Backups doesn’t update:
Have you thought about manually doing the backup? I mean you could FTP/SSH/SFTP/FTPS/rsync/scp the files into S3? I honestly don’t know Amazon’s jazz, so I wouldn’t know if you can just slap the files into Amazon.
@Eliter, thanks for your reply. Yeah, We’re working on that as part of the diagnostic. However we’re not scheduled to migrate for another month, so need to get the automatic backups working again.
@britannic - there has not been much discussion concerning duplicity issues here as evidenced by the lack of response to your post. As your attempt to run a manual backup failed, I am completely unsure that trying what I am about to recommend will be a waste of time or not – but how about trying to change the backup destination to being your MiaB itself. Let the system run for 24-48 hours so that it definitely goes through a daily maintenance cycle once or twice. I am honestly grasping at straws here.
@Alento, we’ll give that a try. Meantime, I working on the theory that duplicity or python was updated during a package upgrade and it broke the backups somehow. I’m working on setting up better logging, because piping the output of backup.py into management/email_administrator.py isn’t providing enough info.
@britannic, if I were you I would make waiting a month unacceptable. On 30 April 2019, Ubuntu 14.04 will reach end-of-life, and it will be very behind on security updates as more vulnerabilities get discovered. You need to upgrade now. It is only a matter of hours until you will NOT get updates or support.
And if you have any business or confidential/sensitive data on that server, I wouldn’t even think that it would be safe after a couple of weeks to a month. After looking at a lot of these security vulnerabilities, it’s not a safe gamble. Plus, there is that time between when a vulnerability is discovered and when it is patched (publicly or privately), which allows for a zero-day attack.
@britannic also, what I meant by manual backup is to not have backup.py script do it, but just use a secure FTP/SSH solution to download/upload the files to the backup device or Amazon, so you don’t waste time trying to get the script to work.
Eli, your comment does lend an idea for a useful kludge if it came down to it. Create another MiaB somewhere … do a rsync of the /home/user-data/ directory - then create an encrypted backup from there. After that, the current VPS can be destroyed and rebuilt if necessary to maintain the current IP.
@Eliter, understood the manual backup which we can do anytime, however, our need is to get the automated backup going, so our system is protected for the next month at least, before the migration.
@Eliter, completely understood about the security issues, and have already created a new server in preparation for the move. I just checked the new server and see that the backups are fine with same credentials, so I’ll concentrate our efforts on the migration.
