Performance Des Backups Vers S3?

[Deneteth]

Bonjour

[Nounours44]

Bonjour,

j'ai constat

[Dex]

2eme piste: je n'ai configur

[Deneteth]

Si comme probablement la majorit

[Dex]

Je refais les r

[Deneteth]

Après quelques essais, voici les premiers éléments de perf sur S3.

1er backup initial:

Sauvegarde de /homes en mode incrémental et envoi crypté. Le Bucket n'existe pas au préalable. Le résultat tel que remonté dans le report Amazon:

• 1,703,844,028 bytes remontés vers S3 en 6 heures (plus petite granularité disponible donc difficile de savoir si la 6 eme heure est pleine ou pas) ce qui nous amène en gros à 78 kbyte/s
• Les problèmes rencontrés:
  • Bucket non créé => création automatique par le Syno sur la platforme S3 par défaut (je suppose), en l'occurrence aux US
  • Plus problématique, le répertoire corbeille commence par un caractère que la Console de gestion S3 ne comprend pas ('#') ce qui crée tout de même un répertoire coté S3 mais qu'il est impossible d'explorer (j'ignore même si il contiens quoi que ce soit). J'ai du désactiver la fonctionnalité Corbeille CIF au niveau du Syno et par sécurité j'ai refait une sauvegarde vers un autre bucket car pour une raison x ou y l'assistant de restoration se plantait en lisant la sauvegarde sur le S3 (ce sont les chiffres de cette seconde sauvegarde que j'ai indiqué au dessus). Je ne sais pas bien comment je vais me débarrasser de ce bucket vérolé d'ailleurs...

2eme backup intial:
Sauvegarde de /photo en mode incrémental et sans cryptage. Le bucket existe au préalable et se trouve en Irlande. Report Amazon:

• 11,787,388,131 bytes remontés vers S3 en 30 heures (même réserve sur la granularité), donc grosso modo 109 KBytes/s. Le cryptage et l'éloignement du bucket sont donc deux réels facteurs de durée pour les backup S3, on a près de 30% d'écart.
• Les problèmes:
  • La configuration de Photostation est systématiquement sauvegardée (ou semble l'être) que l'option soit cochées dans la sauvegarde ou pas. Je le sais parce que j'ai fait un test coché (vers mon bucket vérolé) et un pas choché (vers mon "vrai" bucket) et que dans les deux cas....
  • ... le répertoire créé pour contenir cette configuration sur S3 contiens lui aussi un caractère posant problème Dans ce cas le répertoire s'appelle @tmp/@app/ C'est moins grave que pour les corbeilles car on peut quand même l'explorer et downloader le contenu par contre les objets se retrouvent sans droits sur la console S3, y compris les droits du propriétaire du bucket (je pense que c'est un bug Amazon). Il n'est donc pas possible de supprimer les objets ou de les renommer ou toute action d'administration

Ma première incrémentale sur /homes passe ce soir, je verrai demain si cela marche correctement.

Un conseil de manière générale: pour les sauvegardes n'activez pas de log sur le bucket coté S3: ça ne sert pas à grand chose, ca log beaucoup et ça prend de la place pour rien

Coté couts pour l'instant Amazon m'indique $0, pour juillet mais je pense que tout n'a pas été recalculé depuis que la sauvegarde de /photo est terminée. Par ailleurs le trafic entrant est gratuit jusqu'à septembre il me semble (promo en cours).

Edit: en fait ce n'est pas la configuration de hotostation qui est sauvegardé dans @tmp/@app (bien que ce soit aussi le cas si l'option est cochée) mais la configuration du backup lors de la sauvegarde car le répertoire se trouve dans mes deux buckets. Un autre point que je n'avais pas remarque: le répertoire créé directement à la racine du bucket à le même nom pour toutes les sauvegardes (<nom de host du Syno>_<numéro de serie>), difficile de savoit comment il se débrouille si plusieurs sauvegardes pointent vers le même bucket.

[thierry.]

Salut Deneth,

J'esp