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.
@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, 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.