In more heavily-used instances, or instances that receive large (potentially multi-part) submissions, the size of the submission store may make backup and restore operations over Tor impractical. Anecdotally, the usability cutoff seems to be around the 5GB mark. This is exacerbated by a lack of user feedback during the transfer process in either direction. It would be useful for admins to have a rough idea of download progress.
Some potential changes that would help:
update backup and restore playbooks to optionally save backup on server without transferring it, and provide documentation on how to safely retrieve the backup given physical server access, or via rysnc with resumed partial downloads, and vice versa with restores
update playbooks to support resuming partial transfers (doesn't seem to be supported by synchronize module, might need to wrap rsync)
update playbooks to provide progress feedback for transfers
?YOUR IDEA HERE?
User Research Evidence
[x] Has this idea been influenced by your conversations with users, or by your own experience as a SecureDrop user?
User Stories
As an administrator, I want backups or restores to succeed regardless of the size of the backup file.
Description
In more heavily-used instances, or instances that receive large (potentially multi-part) submissions, the size of the submission store may make backup and restore operations over Tor impractical. Anecdotally, the usability cutoff seems to be around the 5GB mark. This is exacerbated by a lack of user feedback during the transfer process in either direction. It would be useful for admins to have a rough idea of download progress.
Some potential changes that would help:
synchronize
module, might need to wrap rsync)User Research Evidence
User Stories
As an administrator, I want backups or restores to succeed regardless of the size of the backup file.