Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
A few days ago I reinstalled due to a HDD that was causing file corruptions.
Whilst doing the reinstall I took some notes on where I deviated from the official guide for consideration for addition.
Before I done anything I tested my backup locally and it failed due to file corruption. This averted a complete disaster and I strongly recommend it becomes the norm:
duplicity verify --exclude /home/user-data/backup/ file:///home/user-data/backup/encrypted /home/user-data
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Mon Oct 24 10:57:31 2016
Verify complete: 20940 files compared, 0 differences found.
What I also found was that after reinstall I naturally placed the backup file in the the backup folder ultimately causing confusion. I recommend the backup be placed elsewhere and the docs be updated to use real paths along with when to remove the backup (see next).
I also recommend that an immediate new backup be created after successful recovery and that this be verified as well. Once passed the old backup can be deleted from the server.
These are not exactly ground breaking suggestions but as proven above they saved my bacon.
Also duplicty error messages are awful so I post this here so that google helps confused users out later:
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1494, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1488, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1337, in main
do_backup(action)
File "/usr/bin/duplicity", line 1424, in do_backup
verify(col_stats)
File "/usr/bin/duplicity", line 819, in verify
collated = diffdir.collate2iters(restore_get_patched_rop_iter(col_stats),
File "/usr/bin/duplicity", line 719, 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 952, in get_backup_chain_at_time
raise CollectionsError("No backup chains found")
CollectionsError: No backup chains found
simply means you got one of your paths wrong, most liekly the path to the the encrypted backup.
A few days ago I reinstalled due to a HDD that was causing file corruptions.
Whilst doing the reinstall I took some notes on where I deviated from the official guide for consideration for addition.
Before I done anything I tested my backup locally and it failed due to file corruption. This averted a complete disaster and I strongly recommend it becomes the norm:
What I also found was that after reinstall I naturally placed the backup file in the the backup folder ultimately causing confusion. I recommend the backup be placed elsewhere and the docs be updated to use real paths along with when to remove the backup (see next).
I also recommend that an immediate new backup be created after successful recovery and that this be verified as well. Once passed the old backup can be deleted from the server.
These are not exactly ground breaking suggestions but as proven above they saved my bacon.
Also duplicty error messages are awful so I post this here so that google helps confused users out later:
simply means you got one of your paths wrong, most liekly the path to the the encrypted backup.