>>>>> On Mon, 11 May 2020 10:52:23 -0400, Josh Fisher said: > > This is a multi-part message in MIME format. > --===============2027621642792716715== > Content-Type: multipart/alternative; > boundary="------------70CDB63220E9E5545F246201" > Content-Language: en-US > > This is a multi-part message in MIME format. > --------------70CDB63220E9E5545F246201 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 8bit > > > On 5/11/2020 7:38 AM, Kern Sibbald wrote: > > > > Hello Sven, > > > > I share your concerns, but here are a few mitigating factors: > > > > 1. I am not aware of any other C/C++ S3 library that will do the same > > job and is well maintained. I have to admit I have not looked > > recently, so any suggestions would be welcome. > > > > I'm not aware of other C libraries either, but why not use AWS CLI > high-level commands in much the same way that tape autochanger script > commands are implemented? AWS CLI is actively maintained by Amazon and > so shouldn't have the maintenance issues. These are simple mv, cp, ls, > etc. commands somewhat equivalent to their Unix command namesakes. They > shouldn't change even when/if Amazon changes the underlying S3 protocols.
There is also the Amazon's own SDK: https://aws.amazon.com/sdk-for-cpp/ > > > > 2. Bacula Systems actively uses libs3 with its customers, and any > > corrections that they make will also be in the Bacula community libs3 > > git repo (under the same GNU Lesser V3 license) > > > > 3. Amazon (or other s3 supplier's) tools can be used to restore Bacula > > S3 Volumes to disk, and once that is done, Bacula can read those > > volumes regardless of what S3 library it is linked with. This is > > because when the Volumes are on disk, Bacula reads them as standard OS > > files. libs3 is only used to move files from a local disk to and from > > the S3 cloud. > > > > Best regards, > > > > Kern > > > > On 5/10/20 3:24 PM, Sven Hartge wrote: > >> On 10.05.20 15:01, Kern Sibbald wrote: > >> > >>> I agree with Sven, libs3 is a big disaster. It works well but the > >>> author abandoned it, and many things have changed since then. For the > >>> moment, we have a version that works with AWS (don't expect it to work > >>> with a number of other S3 implementations, which are not compatible with > >>> AWS). > >> Adding to that: Other than the horrendous possible security flaws > >> present in libs3 (try to compile with a recent GCC and see for yourself) > >> the nature of anything cloud-bases is inherently volatile. > >> > >> The AWS-API may change at any given moment (and it has in the past), > >> making libs3 incompatible without updates. > >> > >> And without an upstream author implementing those changes, your backups > >> are more or less gone. > >> > >> My very pessimistic view on the situation is: Don't use any backup > >> solution using libs3 if you value your data. > >> > >> But: YMMV. > >> > >> Grüße, > >> Sven. > >> > >> > >> > >> _______________________________________________ > >> Bacula-users mailing list > >> Bacula-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users > _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
