Um meine Daten nach Amazon S3 zu sichern, habe ich mich unter der vielzahl verfügbarer Tools für S3Sync entschieden. Da dieses in ruby geschriebene Tools sich an rsync anlehnt und es auch unter Amazon EC2 wertvolle Dienste erbringt um das flüchtige Filesystem der virtuellen Server persistent zu halten, ist es für mich die erste Wahl.

Auf einer Debian (oder auch Ubuntu) basierten Linux Distribution erfolgt die Installation mit:

[CODE]
# Ruby (>=1.8.4) und die OpenSSL ruby library werden benötigt
$ sudo apt-get install ruby libopenssl-ruby
# In das Verzeichnis in das s3sync installiert werden soll
$ cd /home/user/
# s3sync downloaden und entpacken
$ wget http://s3.amazonaws.com/ServEdge_pub/s3sync/s3sync.tar.gz
$ tar xvzf s3sync.tar.gz; rm s3sync.tar.gz
# das s3config.yml mit Umgebungsvariablen füllen
cp s3config.yml.example s3config.yml
# Das yml nur für den Owner lesbar machen
chmod 600 s3config.yml
vi s3config.yml
# aws_access_key_id: 11111111111111111111111
# aws_secret_access_key: 222222222222222222222
# ssl_cert_file: /home/user/s3sync/my_ssl_cert
# (hier nun die eigenen AWS Daten eintragen)
[/CODE]

Das Verwenden der yml Datei wurde erst in einer späten Version von s3sync hinzugefügt. Es erspart das Setzen der Umgebungsvariablen bevor das s3sync Script aufgerufen wird.

Ein Beispiel für ein SSL_CERT_FILE wird im Readme von s3sync gegeben.

Besitzer, Gruppe und Rechte bleiben mit s3sync erhalten. Leider gehen mir aber die Timestamps verloren.

Weiterführende Dokumentation gibt es hier. In diesem Beispiel wird auch gezeigt wie man s3sync auf einer ec2 Instanz einsetzt.

Jeder Benutzer kann bis zu 100 Buckets erstellen. Da die Buckets bei öffentlichen Dateien als Teil der URL erscheinen sollte man sich hier sprechende und kurze Namen überlegen (sofern diese noch frei sind). Jedes Bucket kann man wie ein logisches Laufwerk betrachten. Daher ist es auch möglich in unterschiedlichen Buckets unterschiedliche Inhalte/Strukturen zu verwenden. Es spricht also nichts dagegen mit einem S3 Benutzerkonto JungleDisk oder andere S3 basierte Tools und S3Sync parallel in getrennten Buckets zu verwenden.

Während der Evaluierungsphase habe ich neben s3cmd.rb auch S3Fox verwendet um den Inhalt meiner mit s3sync.rb gefüllten Buckets zu kontrollieren. Wie auch bei rsync schätze ich den Vorteil, dass ich die erstellten Backups – anders als bei tar oder Duplicity – direkt betrachten, kontrollieren und nutzen kann. Da jede Datei in einem Key/Blob abgelegt wird, kann man leicht einzelne Dateien restaurieren oder über die S3 ACL öffentlich zugänglich machen. Leider hat S3Fox Probleme die von s3sync gefüllten Buckets darzustellen. Im s3sync Readme (Changelog) gibt der Autor dazu folgenden Hinweis:

In the case of commands of the form:
s3sync -r somedir somebucket:
The root directory node in s3 was being stored as “somedir/” instead of “somedir”
which caused restores to mess up when you say:
s3sync -r somebucket: restoredir
The fix to this, by coincidence, actually makes s3fox work even *less* well with
s3sync. I really need to build my own xul+javascript s3 GUI some day.

Anstatt von S3Fox nutze ich nun den Mac OS X S3 Browser.

Alternativen zu S3Sync?
Für umfangreichere Backups mag der s3sync Ansatz weniger geeignet sein, denn aufgrund der Architektur von S3 muss s3sync für jede Datei einen Request an S3 senden, was viel Bandbreite und Zeit verbrauchen kann.

Aus diesem Grund wäre eigentlich Duplicity die bessere Wahl um umfangreiche Datenmengen bzw. viele Dateien auf S3 zu sichern. Duplicity verfolgt einen ganz anderen Ansatz und ist damit in der Lage sehr bandbreitenschonend Backups zu erstellen. Seit der Version 0.4.3.RC9 (2007/07/09) unterstützt Duplicity auch S3 nativ als Backend.
Für mein Vorhaben ist Duplicity jedoch weniger geeigent, da die gesicherten Dateien nicht mehr im “direkten” Zugriff in S3 verfügbar sind sondern in encrypted und signierten Archiven abgelegt werden. Da inkrementell gesichert wird, wird der erforderliche Speicherplatz immer größer da Archive nicht gelöscht werden können solange nicht eine erneute Vollständige Sicherung gemacht wird. Eine vollständige Sicherung auf S3 verbraucht jedoch wieder enorme Bandbreite / Traffic und Zeit. Und immer nur inkrementell zu sichern erscheint mir auch nicht ratsam.

Bestrebungen S3 über ein Filesystem nutzbar zu machen (S3/Fuse, JungleDisk u.a.) um dieses dann per rsync nutzen zu können erscheinen mir aber auch nicht vielversprechend, da die S3 API nur sehr grundlegende Funktionen bereitstellt (z.b. kein Seek in einem Blob; ändert sich ein Blob, so muss er komplett neu hochgeladen werden), so dass die Vorteile von rsync hier nicht ausgespielt werden können.

Allerdings wäre S3/fuse natürlich eine KillerApp. Insbesondere auch für EC2 um so ein persistentes Filesystem zu erhalten.