MVP of securebox-backup-archive-s3 (upload timestamped archived project on remote S3 compatible storage)

[fititnt]

See also:

• https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services
• Potential cli agents
  • https://github.com/s3tools/s3cmd
  • https://duck.sh/
  • https://github.com/cosmin/s3-bash
  • Maybe even some shell kung fu?
    • https://gist.github.com/chrismdp/6c6b6c825b07f680e710
    • http://tmont.com/blargh/2014/1/uploading-to-s3-in-bash

---

Isse about implement an minimum viable product (MVP) upload timestamped archived project on remote S3 compatible storage.

This issue implicitly depends on the another issue be ready first, the securebox-backup-archive-locally (see MVP of securebox-backup-archive-locally (save timestamped archived project) #1), but most of shared functionality can be on the securebox-backup-library.sh. Yet some code duplication with securebox-backup-archive-locally may actually be acceptable if it could make more easier to maintain or people create their own versions.

One thing that maybe is a good default for all securebox-backup-archive-* is, even if could not use temporary directory, we do it anyway. The securebox-backup-archive-locally in in some cases could output files from the local mirrored copy (default: /backups/mirror/...) directly on the archived path (default: /backups/archives/...). Yes, I understated that one implication of this is that both securebox-backup-archive-locally and securebox-backup-archive-s3 could end with like almost 60-70% of near equivalent code, but I think that, for the end user, the complete different command names can be more intuitive than an extra flag. This could play a very nice combo with the config files.