Funktionen der PostgreSQL-Sicherungsmethode in AWS S3

Amazon veröffentlichte S3 Anfang 2006 und das erste Tool, mit dem PostgreSQL-Sicherungsskripte Daten in die Cloud hochladen konnten – s3cmd – wurde knapp ein Jahr später geboren. Bis 2010 (nach meinen Fähigkeiten bei der Google-Suche) Open BI-Blogs darüber. Man kann also mit Sicherheit sagen, dass einige der PostgreSQL-DBAs seit 9 Jahren Daten auf AWS S3 sichern. Aber wie? Und was hat sich in dieser Zeit verändert? Während s3cmd immer noch von einigen im Zusammenhang mit bekannten PostgreSQL-Backup-Tools referenziert wird, wurden die Methoden geändert, um eine bessere Integration mit entweder dem Dateisystem oder den nativen PostgreSQL-Backup-Optionen zu ermöglichen, um die gewünschten Wiederherstellungsziele RTO und RPO zu erreichen.

Warum Amazon S3

Wie in der gesamten Amazon S3-Dokumentation (die S3-FAQs sind ein sehr guter Ausgangspunkt) erwähnt, sind die Vorteile der Verwendung des S3-Dienstes:

99,999999999 (elf Neunen) Haltbarkeit
unbegrenzter Datenspeicher
niedrige Kosten (noch niedriger in Kombination mit BitTorrent)
eingehender Netzwerkverkehr kostenlos
Nur ausgehender Netzwerkverkehr ist kostenpflichtig

AWS S3 CLI Fallstricke

Das AWS S3 CLI-Toolkit bietet alle Tools, die zum Übertragen von Daten in und aus dem S3-Speicher benötigt werden. Warum also nicht diese Tools verwenden? Die Antwort liegt in den Amazon S3-Implementierungsdetails, die Maßnahmen zum Umgang mit den Beschränkungen und Einschränkungen im Zusammenhang mit der Objektspeicherung enthalten:

Maximale Größe von 5 TB pro gespeichertem Objekt
5 GB maximale Größe eines PUT-Objekts
Mehrteiliger Upload wird für Objekte mit mehr als 100 MB empfohlen
Wählen Sie eine geeignete Speicherklasse gemäß dem S3-Leistungsdiagramm aus
Nutzen Sie die Vorteile des S3-Lebenszyklus
S3-Datenkonsistenzmodell

Als Beispiel siehe die aws s3 cp-Hilfeseite:

--expected-size (string) Dieses Argument gibt die erwartete Größe eines Streams in Bytes an. Beachten Sie, dass dieses Argument nur benötigt wird, wenn ein Stream auf s3 hochgeladen wird und die Größe größer als 5 GB ist. Wird dieses Argument unter diesen Bedingungen nicht angegeben, kann der Upload aufgrund zu vieler Teile im Upload fehlschlagen.

Um diese Fallstricke zu vermeiden, sind fundierte Kenntnisse des S3-Ökosystems erforderlich, und genau das versuchen die speziell entwickelten PostgreSQL- und S3-Backup-Tools zu erreichen.

Native PostgreSQL-Backup-Tools mit Amazon S3-Unterstützung

S3-Integration wird von einigen der bekannten Sicherungstools bereitgestellt, die die nativen Sicherungsfunktionen von PostgreSQL implementieren.

BarkeeperS3

BarmanS3 ist als Barman Hook Script implementiert. Es stützt sich auf AWS CLI, ohne auf die oben aufgeführten Empfehlungen und Einschränkungen einzugehen. Die einfache Einrichtung macht es zu einem guten Kandidaten für kleine Installationen. Die Entwicklung ist etwas ins Stocken geraten, letztes Update vor etwa einem Jahr, was dieses Produkt zu einer Wahl für diejenigen macht, die Barman bereits in ihren Umgebungen verwenden.

S3-Dumps

S3dumps ist ein aktives Projekt, das mit der Python-Bibliothek Boto3 von Amazon implementiert wurde. Die Installation erfolgt einfach über pip. Obwohl Sie sich auf das Amazon S3 Python SDK verlassen, zeigt eine Suche im Quellcode nach Regex-Schlüsselwörtern wie multi.*part oder storage.*class keine der erweiterten S3-Funktionen, wie z. B. mehrteilige Übertragungen.

pgBackRest

pgBackRest implementiert S3 als Repository-Option. Dies ist eines der bekannten PostgreSQL-Backup-Tools, das eine funktionsreiche Reihe von Backup-Optionen wie paralleles Backup und Wiederherstellung, Verschlüsselung und Tablespace-Unterstützung bietet. Es ist hauptsächlich C-Code, der die Geschwindigkeit und den Durchsatz bietet, die wir suchen, aber wenn es um die Interaktion mit der AWS S3-API geht, geht dies zu Lasten der zusätzlichen Arbeit, die für die Implementierung der S3-Speicherfunktionen erforderlich ist. Die neueste Version implementiert den mehrteiligen S3-Upload.

WAL-G

WAL-G, das vor 2 Jahren angekündigt wurde, wird aktiv gewartet. Dieses solide PostgreSQL-Sicherungstool implementiert Speicherklassen, aber keinen mehrteiligen Upload (das Durchsuchen des Codes für CreateMultipartUpload hat kein Vorkommen gefunden).

PGHoard

pghoard wurde vor etwa 3 Jahren veröffentlicht. Es ist ein leistungsstarkes und funktionsreiches PostgreSQL-Backup-Tool mit Unterstützung für mehrteilige S3-Übertragungen. Es bietet keine der anderen S3-Funktionen wie Speicherklassen- und Objektlebenszyklusverwaltung.

S3 als lokales Dateisystem

Die Möglichkeit, auf S3-Speicher als lokales Dateisystem zuzugreifen, ist eine sehr erwünschte Funktion, da es die Möglichkeit eröffnet, die nativen Backup-Tools von PostgreSQL zu verwenden.

Für Linux-Umgebungen bietet Amazon zwei Optionen an:NFS und iSCSI. Sie nutzen das AWS Storage Gateway.

NFS

Eine lokal gemountete NFS-Freigabe wird vom AWS Storage Gateway File-Service bereitgestellt. Gemäß dem Link müssen wir ein File Gateway erstellen.

Wählen Sie auf dem Bildschirm Hostplattform auswählen Amazon EC2 aus und klicken Sie auf die Schaltfläche Instanz starten um den EC2-Assistenten zum Erstellen der Instanz zu starten.

Lassen Sie uns nun aus reiner Neugier dieses Sysadmins das vom Assistenten verwendete AMI untersuchen, da es uns eine interessante Perspektive auf einige der internen Teile von AWS gibt. Mit der bekannten Bild-ID ami-0bab9d6dffb52fef5 schauen wir uns die Details an:

Wie oben gezeigt, lautet der AMI-Name aws-thinstaller – also was ist ein „thinstaller“? Internetrecherchen zeigen, dass Thinstaller ein Softwarekonfigurations-Management-Tool von IBM Lenovo für Microsoft-Produkte ist, auf das zuerst in diesem Blog von 2008 und später in diesem Lenovo-Forumsbeitrag und dieser Serviceanfrage des Schulbezirks verwiesen wird. Ich hatte keine Möglichkeit, das zu wissen, da mein Job als Windows-Systemadministrator 3 Jahre zuvor endete. Also wurde dieses AMI mit dem Thinstaller-Produkt erstellt. Um die Sache noch verwirrender zu machen, wird das AMI-Betriebssystem als „Anderes Linux“ aufgeführt, was durch SSH-Eingabe in das System als Administrator bestätigt werden kann.

Ein Fehler im Assistenten:Trotz der Einrichtungsanweisungen für die EC2-Firewall kam es bei meinem Browser zu einer Zeitüberschreitung, als er sich mit dem Speicher-Gateway verband. Das Zulassen von Port 80 ist unter Portanforderungen dokumentiert – wir könnten argumentieren, dass der Assistent entweder alle erforderlichen Ports auflisten oder auf die Dokumentation verlinken sollte, aber im Geiste der Cloud lautet die Antwort „automatisieren“ mit Tools wie CloudFormation.

Der Assistent schlägt außerdem vor, mit einer xlarge-Instanz zu beginnen.

Sobald das Speichergateway bereit ist, konfigurieren Sie die NFS-Freigabe, indem Sie auf Erstellen klicken Dateifreigabe-Schaltfläche im Gateway-Menü:

Sobald die NFS-Freigabe bereit ist, befolgen Sie die Anweisungen zum Mounten des Dateisystems:

Beachten Sie im obigen Screenshot, dass der mount-Befehl auf die private IP-Adresse der Instanz verweist die Anschrift. Um von einem öffentlichen Host zu mounten, verwenden Sie einfach die öffentliche Adresse der Instanz, wie oben in den EC2-Instanzdetails gezeigt.

Der Assistent blockiert nicht, wenn der S3-Bucket zum Zeitpunkt der Erstellung der Dateifreigabe nicht vorhanden ist. Sobald der S3-Bucket jedoch erstellt ist, müssen wir die Instanz neu starten, andernfalls den Mount-Befehl schlägt fehl mit:

[[email protected] ~]# mount -t nfs -o nolock,hard 34.207.216.29:/s9s-postgresql-backup /mnt

mount.nfs: mounting 34.207.216.29:/s9s-postgresql-backup failed, reason given by server: No such file or directory

Überprüfen Sie, ob die Freigabe verfügbar gemacht wurde:

[[email protected] ~]# df -h /mnt

Filesystem                            Size Used Avail Use% Mounted on

34.207.216.29:/s9s-postgresql-backup  8.0E 0 8.0E 0% /mnt

Lassen Sie uns jetzt einen schnellen Test durchführen:

[email protected][local]:54311 postgres# \l+ test

                                                List of databases

Name |  Owner | Encoding |   Collate | Ctype | Access privileges |  Size | Tablespace | Description

------+----------+----------+-------------+-------------+-------------------+---------+------------+-------------

test | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                   | 2763 MB | pg_default |

(1 row)

[[email protected] ~]# date ; time pg_dump -d test | gzip -c >/mnt/test.pg_dump.gz ; date

Sun 27 Oct 2019 06:06:24 PM PDT



real    0m29.807s

user    0m15.909s

sys     0m2.040s

Sun 27 Oct 2019 06:06:54 PM PDT

Beachten Sie, dass der Zeitstempel der letzten Änderung im S3-Bucket etwa eine Minute später liegt, was, wie bereits erwähnt, mit dem Amazon S3-Datenkonsistenzmodell zusammenhängen muss.

Hier ist ein umfassenderer Test:

~ $ for q in {0..20} ; do touch /mnt/touched-at-$(date +%Y%m%d%H%M%S) ;

sleep 1 ; done



~ $ aws s3 ls s3://s9s-postgresql-backup | nl

    1      2019-10-27 19:50:40          0 touched-at-20191027194957

    2      2019-10-27 19:50:40          0 touched-at-20191027194958

    3      2019-10-27 19:50:40          0 touched-at-20191027195000

    4      2019-10-27 19:50:40          0 touched-at-20191027195001

    5      2019-10-27 19:50:40          0 touched-at-20191027195002

    6      2019-10-27 19:50:40          0 touched-at-20191027195004

    7      2019-10-27 19:50:40          0 touched-at-20191027195005

    8      2019-10-27 19:50:40          0 touched-at-20191027195007

    9      2019-10-27 19:50:40          0 touched-at-20191027195008

   10      2019-10-27 19:51:10          0 touched-at-20191027195009

   11      2019-10-27 19:51:10          0 touched-at-20191027195011

   12      2019-10-27 19:51:10          0 touched-at-20191027195012

   13      2019-10-27 19:51:10          0 touched-at-20191027195013

   14      2019-10-27 19:51:10          0 touched-at-20191027195014

   15      2019-10-27 19:51:10          0 touched-at-20191027195016

   16      2019-10-27 19:51:10          0 touched-at-20191027195017

   17      2019-10-27 19:51:10          0 touched-at-20191027195018

   18      2019-10-27 19:51:10          0 touched-at-20191027195020

   19      2019-10-27 19:51:10          0 touched-at-20191027195021

   20      2019-10-27 19:51:10          0 touched-at-20191027195022

   21      2019-10-27 19:51:10          0 touched-at-20191027195024

Ein weiteres erwähnenswertes Problem:Nachdem ich mit verschiedenen Konfigurationen herumgespielt, Gateways und Freigaben erstellt und zerstört hatte, erhielt ich irgendwann beim Versuch, ein Datei-Gateway zu aktivieren, einen internen Fehler:

Die Befehlszeile enthält einige weitere Details, obwohl sie nicht auf ein Problem hinweist:

~$ curl -sv "http://107.22.30.30/?gatewayType=FILE_S3&activationRegion=us-east-1"

*   Trying 107.22.30.30:80...

* TCP_NODELAY set

* Connected to 107.22.30.30 (107.22.30.30) port 80 (#0)

> GET /?gatewayType=FILE_S3&activationRegion=us-east-1 HTTP/1.1

> Host: 107.22.30.30

> User-Agent: curl/7.65.3

> Accept: */*

>

* Mark bundle as not supporting multiuse

< HTTP/1.1 500 Internal Server Error

< Date: Mon, 28 Oct 2019 06:33:30 GMT

< Content-type: text/html

< Content-length: 14

<

* Connection #0 to host 107.22.30.30 left intact

Internal Error~ $

In diesem Forumsbeitrag wurde darauf hingewiesen, dass mein Problem möglicherweise etwas mit dem von mir erstellten VPC-Endpunkt zu tun hat. Meine Lösung bestand darin, den VPC-Endpunkt zu löschen, den ich während verschiedener iSCSI-Trial-and-Error-Läufe eingerichtet hatte.

Während S3 ruhende Daten verschlüsselt, ist der NFS-Datenverkehr Klartext. Hier ist nämlich ein tcpdump-Paket-Dump:

23:47:12.225273 IP 192.168.0.11.936 > 107.22.30.30.2049: Flags [P.], seq 2665:3377, ack 2929, win 501, options [nop,nop,TS val 1899459538 ecr 38013066], length 712: NFS request xid 3511704119 708 getattr fh 0,2/53

[email protected]@.......k.......        ...c..............

q7s..D.......PZ7...........................4........omiday.can.local...................................................5.......]...........!....................C...

..............&...........]....................# inittab is no longer used.

#

# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

#

# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target

#

# systemd uses 'targets' instead of runlevels. By default, there are two main targets:

#

# multi-user.target: analogous to runlevel 3

# graphical.target: analogous to runlevel 5

#

# To view current default target, run:

# systemctl get-default

#

# To set a default target, run:

# systemctl set-default TARGET.target

.....   .........0..

23:47:12.331592 IP 107.22.30.30.2049 > 192.168.0.11.936: Flags [P.], seq 2929:3109, ack 3377, win 514, options [nop,nop,TS val 38013174 ecr 1899459538], length 180: NFS reply xid 3511704119 reply ok 176 getattr NON 4 ids 0/33554432 sz -2138196387

Bis dieser IEE-Entwurf genehmigt ist, ist die einzige sichere Option für eine Verbindung von außerhalb von AWS die Verwendung eines VPN-Tunnels. Dies verkompliziert die Einrichtung und macht die On-Premise-NFS-Option weniger attraktiv als die FUSE-basierten Tools, auf die ich etwas später eingehen werde.

iSCSI

Diese Option wird vom AWS Storage Gateway Volume-Service bereitgestellt. Sobald der Dienst konfiguriert ist, gehen Sie zum Setup-Abschnitt des Linux-iSCSI-Clients.

Der Vorteil der Verwendung von iSCSI gegenüber NFS besteht in der Möglichkeit, die Vorteile der Cloud-nativen Sicherungs-, Klon- und Snapshot-Dienste von Amazon zu nutzen. Für Details und Schritt-für-Schritt-Anleitungen folgen Sie den Links zu AWS Backup, Volume Cloning und EBS Snapshots

Während es viele Vorteile gibt, gibt es eine wichtige Einschränkung, die wahrscheinlich viele Benutzer abschrecken wird:Es ist nicht möglich, über seine öffentliche IP-Adresse auf das Gateway zuzugreifen. Genau wie die NFS-Option erhöht diese Anforderung also die Komplexität der Einrichtung.

Trotz der klaren Einschränkung und der Überzeugung, dass ich dieses Setup nicht schaffen werde, wollte ich dennoch ein Gefühl dafür bekommen, wie es geht. Der Assistent leitet zu einem AWS Marketplace-Konfigurationsbildschirm weiter.

Beachten Sie, dass der Marketplace-Assistent eine sekundäre Festplatte erstellt, die jedoch nicht groß genug ist Größe, und daher müssen wir noch die beiden erforderlichen Volumes hinzufügen, wie in den Host-Setup-Anweisungen angegeben. Wenn die Speicheranforderungen nicht erfüllt sind, blockiert der Assistent im Konfigurationsbildschirm für lokale Festplatten:

Hier ist ein Blick auf den Amazon Marketplace-Konfigurationsbildschirm:

Es gibt eine Textschnittstelle, auf die über SSH zugegriffen werden kann (melden Sie sich als Benutzer sguser an). das grundlegende Tools zur Netzwerkfehlerbehebung und andere Konfigurationsoptionen bereitstellt, die nicht über die Web-GUI ausgeführt werden können:

~ $ ssh [email protected]

Warning: Permanently added 'ec2-3-231-96-109.compute-1.amazonaws.com,3.231.96.109' (ECDSA) to the list of known hosts.

'screen.xterm-256color': unknown terminal type.




      AWS Storage Gateway Configuration



      #######################################################################

      ##  Currently connected network adapters:

      ##

      ##  eth0: 172.31.1.185

      #######################################################################



      1: SOCKS Proxy Configuration

      2: Test Network Connectivity

      3: Gateway Console

      4: View System Resource Check (0 Errors)



      0: Stop AWS Storage Gateway



      Press "x" to exit session



      Enter command:

Und ein paar andere wichtige Punkte:

Im Gegensatz zum NFS-Setup gibt es keinen direkten Zugriff auf den S3-Speicher, wie im FAQ-Bereich von Volume Gateway erwähnt.
Die AWS-Dokumentation besteht darauf, die iSCSI-Einstellungen anzupassen, um die Leistung und Sicherheit der Verbindung zu verbessern.

SICHERUNG

In dieser Kategorie habe ich die FUSE-basierten Tools aufgelistet, die im Vergleich zu den PostgreSQL-Backup-Tools eine vollständigere S3-Kompatibilität bieten und im Gegensatz zu Amazon Storage Gateway Datenübertragungen von einem lokalen Host ermöglichen zu Amazon S3 ohne zusätzliche Konfiguration. Ein solches Setup könnte S3-Speicher als lokales Dateisystem bereitstellen, das PostgreSQL-Backup-Tools verwenden können, um Funktionen wie paralleles pg_dump zu nutzen.

s3fs-Sicherung

s3fs-fuse ist in C++ geschrieben, einer Sprache, die vom Amazon S3 SDK-Toolkit unterstützt wird, und eignet sich daher gut für die Implementierung erweiterter S3-Funktionen wie mehrteilige Uploads, Caching, S3-Speicherklasse, Server- Seitenverschlüsselung und Regionsauswahl. Es ist auch sehr POSIX-kompatibel.

Die Anwendung ist in meinem Fedora 30 enthalten, was die Installation einfach macht.

Zum Testen:

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz

real    0m35.761s

user    0m16.122s

sys     0m2.228s

~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 03:16:03   79110010 test.pg_dump-20191028-031535.gz

Beachten Sie, dass die Geschwindigkeit etwas langsamer ist als bei Verwendung des Amazon Storage Gateway mit der NFS-Option. Es gleicht die geringere Leistung aus, indem es ein hochgradig POSIX-kompatibles Dateisystem bereitstellt.

S3QL

S3QL bietet S3-Funktionen wie Speicherklasse und serverseitige Verschlüsselung. Die vielen Funktionen sind in der ausführlichen S3QL-Dokumentation beschrieben, wenn Sie jedoch nach einem mehrteiligen Upload suchen, wird dies nirgendwo erwähnt. Dies liegt daran, dass S3QL einen eigenen Dateiaufteilungsalgorithmus implementiert, um die Deduplizierungsfunktion bereitzustellen. Alle Dateien sind in 10-MB-Blöcke aufgeteilt.

Die Installation auf einem Red Hat-basierten System ist unkompliziert:Installieren Sie die erforderlichen RPM-Abhängigkeiten über yum:

sqlite-devel-3.7.17-8.14.amzn1.x86_64

fuse-devel-2.9.4-1.18.amzn1.x86_64

fuse-2.9.4-1.18.amzn1.x86_64

system-rpm-config-9.0.3-42.28.amzn1.noarch

python36-devel-3.6.8-1.14.amzn1.x86_64

kernel-headers-4.14.146-93.123.amzn1.x86_64

glibc-headers-2.17-260.175.amzn1.x86_64

glibc-devel-2.17-260.175.amzn1.x86_64

gcc-4.8.5-1.22.amzn1.noarch

gcc48-4.8.5-28.142.amzn1.x86_64

mpfr-3.1.1-4.14.amzn1.x86_64

libmpc-1.0.1-3.3.amzn1.x86_64

libgomp-6.4.1-1.45.amzn1.x86_64

libgcc48-4.8.5-28.142.amzn1.x86_64

cpp48-4.8.5-28.142.amzn1.x86_64

python36-pip-9.0.3-1.26.amzn1.noarch

python36-libs-3.6.8-1.14.amzn1.x86_64

python36-3.6.8-1.14.amzn1.x86_64

python36-setuptools-36.2.7-1.33.amzn1.noarch

Installieren Sie dann die Python-Abhängigkeiten mit pip3:

pip-3.6 install setuptools cryptography defusedxml apsw dugong pytest requests llfuse==1.3.6

Ein bemerkenswertes Merkmal dieses Tools ist das S3QL-Dateisystem, das auf dem S3-Bucket erstellt wird.

Dummköpfe

goofys ist eine Option, wenn die Leistung die POSIX-Konformität übertrumpft. Seine Ziele sind das Gegenteil von s3fs-fuse. Der Fokus auf Geschwindigkeit spiegelt sich auch im Vertriebsmodell wider. Für Linux gibt es vorgefertigte Binärdateien. Führen Sie nach dem Herunterladen Folgendes aus:

~/temp/goofys $ ./goofys s9s-postgresql-backup ~/mnt/s9s/

Und Sicherung:

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz



real    0m27.427s

user    0m15.962s

sys     0m2.169s



~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 04:29:05   79110010 test.pg_dump-20191028-042902.gz

Beachten Sie, dass die Objekterstellungszeit auf S3 nur 3 Sekunden vom Dateizeitstempel entfernt ist.

ObjectFS

ObjectFS scheint bis vor etwa 6 Monaten gewartet worden zu sein. Eine Prüfung auf mehrteiligen Upload zeigt, dass es nicht implementiert ist. Aus dem Forschungspapier des Autors erfahren wir, dass sich das System noch in der Entwicklung befindet, und seit das Papier im Jahr 2019 veröffentlicht wurde, dachte ich, es wäre erwähnenswert.

S3-Clients

Wie bereits erwähnt, müssen wir zur Verwendung der AWS S3 CLI mehrere Aspekte berücksichtigen, die für die Objektspeicherung im Allgemeinen und Amazon S3 im Besonderen spezifisch sind. Wenn die einzige Anforderung die Möglichkeit ist, Daten in den und aus dem S3-Speicher zu übertragen, kann ein Tool, das sich eng an die Amazon S3-Empfehlungen hält, die Arbeit erledigen.

s3cmd ist eines der Tools, das sich bewährt hat. Dieser Open BI-Blog von 2010 spricht darüber, zu einer Zeit, als S3 das neue Kind auf dem Block war.

Bemerkenswerte Eigenschaften:

serverseitige Verschlüsselung
automatische mehrteilige Uploads
Bandbreitendrosselung

Weitere Informationen finden Sie in der S3cmd:FAQ und Wissensdatenbank.

Fazit

Die verfügbaren Optionen zum Sichern eines PostgreSQL-Clusters auf Amazon S3 unterscheiden sich in den Datenübertragungsmethoden und wie sie mit den Amazon S3-Strategien übereinstimmen.

AWS Storage Gateway ergänzt den S3-Objektspeicher von Amazon, auf Kosten erhöhter Komplexität zusammen mit zusätzlichem Wissen, das erforderlich ist, um das Beste aus diesem Service herauszuholen. Beispielsweise erfordert die Auswahl der richtigen Anzahl von Festplatten eine sorgfältige Planung, und ein guter Überblick über die mit S3 verbundenen Kosten von Amazon ist ein Muss, um die Betriebskosten zu minimieren.

Die Entscheidung, die Daten in einer öffentlichen Cloud zu speichern, gilt zwar für jeden Cloud-Speicher, nicht nur für Amazon S3, hat jedoch Auswirkungen auf die Sicherheit. Amazon S3 bietet Verschlüsselung für ruhende Daten und Daten während der Übertragung, ohne Garantie für Zero-Knowledge oder No-Knowledge-Beweise. Organisationen, die die volle Kontrolle über ihre Daten haben möchten, sollten eine clientseitige Verschlüsselung implementieren und die Verschlüsselungsschlüssel außerhalb ihrer AWS-Infrastruktur speichern.

Für kommerzielle Alternativen zur Zuordnung von S3 zu einem lokalen Dateisystem lohnt es sich, die Produkte von ObjectiveFS oder NetApp zu prüfen.

Schließlich sollten Unternehmen, die ihre eigenen Backup-Tools entwickeln möchten, indem sie entweder auf der Grundlage der vielen Open-Source-Anwendungen aufbauen oder ganz von vorne beginnen, den S3-Kompatibilitätstest verwenden, der vom Ceph-Projekt zur Verfügung gestellt wird.