Salut,
Oui c'est l'outil que j'utilise et je suis scrupuleusement la doc. Ca simplifie la configuration de rclone.
Mais de ce que je constate, comme je l'ai dit plus haut, ca utilise la connexion du poste sur lequel est lancé la commande comme intermédiaire. Hier, j'ai réussi à transférer 70 Go, là je termine avec les 15 derniers Go. L'outil m'annonce 18 minutes pour faire le transfert.
Je pense faire parti des chanceux qui n'ont qu'une petite quantité de données à migrer.
J'ai rencontré des problèmes au début de la migration, à cause d'une mauvaise compréhension de la doc (sur la taille des chunks qui n'est pas clair du tout) qui a conduit à des erreurs sur certains fichiers que j'ai du renvoyer à la main. Une fois la config remise par défaut, tout s'est déroulé sans erreur.
Effectivement, le tuto fourni n'est qu'une assistance à l'utilisation d'rclone.
Chaque archive C14 classic est désarchivée, puis les données sont téléchargées
sur le PC, pour être réimportées dans un "Object storage" C14 Cold Storage.
J'ai eu pitié d'un ami qui avait archivé près d'1To chez C14 classic depuis sa connexion ADSL, et qui allait devoir tout retransférer
Je lui ai donné un accès SSH à une de mes machines, pour qu'il puisse exploiter ma connexion fibre.
De plus, j'ai constaté plusieurs limitations de la nouvelle solution C14 Cold Storage :
-
La nouvelle plateforme ne semble pas adaptée à l'archivage de nombreux petits fichiers.
Chaque commande "aws s3 cp" prend un temps incompressible pour chaque fichier, faisant chuter drastiquement le taux de transfert moyen en présence de nombreux petits fichiers (jusqu'à < 10 ko/sec !!!).
-
Les caractères pris en charge dans les noms d'objets semblent limités. Cf.
doc S3.
Ce qui est piégeux, c'est que la commande "aws s3 cp" accepte les caractères problématiques (espaces, caractères accentués ...) sans broncher.
Mais j'ai constaté sur certains de ces fichiers, qu'il m'était impossible de les récupérer (opération de changement de classe CLASSIER > CLASSIC qui dure des heures et n'aboutit jamais).
Du fait de ces limitations, il est nécessaire de réorganiser ses données avant de les migrer :
- Grouper les fichiers dans des archives (ex : un fichier zip par dossier photos), afin de limiter les nombreux petits fichiers
- Supprimer les caractères problématiques
J'ai automatisé cette tâche à l'aide d'un script bash :
#!/bin/bash
if [ "$#" -lt 3 ] ; then
echo "$0 <bucket-name> <bucket-subdir> <file1|dir1> [file2|dir2] ..."
exit 1
fi
BUCKET_NAME=${1}
BUCKET_SUBDIR=${2}
TEMP_DIR="/media/dd/Media/Temp/"
# Tant qu'il reste des fichiers/dossiers à zipper
while [ ! -z "${3}" ] ; do
to_zip=$(basename "${3}")
# Remplacement des caractères accentués, par leurs équivalents non accentués
# + Remplacement par "_" des caractères autres que ceux autorisés
# cf. https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html#object-key-guidelines
zip_file=$(echo -n "${to_zip}.zip" | iconv -f utf8 -t ascii//TRANSLIT | tr -c 'A-Za-z0-9_.\-\(\)' '_')
# Afficher les commandes avant exécution
set -x
# Zip (0% de compression) + envoi du zip vers AWS S3 GLACIER
zip -Z store -r "${TEMP_DIR}/${zip_file}" "${to_zip}" && \
aws s3 cp "${TEMP_DIR}/${zip_file}" "s3://${BUCKET_NAME}/${BUCKET_SUBDIR}/" --storage-class GLACIER && \
rm "${TEMP_DIR}/${zip_file}"
# Désactivation set -x
{ set +x ;} 2> /dev/null
# Argument++
shift
done
Certains ici utilisent le service object-storage de Scaleway ? Et leur option Cold storage ?
J'ai très très régulièrement des problèmes pour restaurer des objets depuis GLACIER. Parfois ça se fait en quelques minutes, d'autres fois rien du tout après plusieurs jours. Obligé de contacter le support, et comme par magie quelques heures après le fichier sort du glacier. Parfois avec une explication du support (les espaces dans les noms d'objets n'étaient pas pris en charge LOL), parfois juste ils "constatent" que le fichier a été restauré, comme par hasard après plusieurs jours et après les avoir contacté...
C'est super relou, c'est censé être un truc automatique. Je comprend bien le délais pour la restauration, ça peut s'automatiser sans soucis. Mais s'il faut contacter le support pour débloquer une situation c'est nul.
Sans compter que le support est assez chaotique. Une fois sur 2, on tombe sur un N1 qui n'y connait rien et répond à côté. Quand il comprend et transfère au N2, le N2 répond en demandant des infos. On envoit la réponse, c'est un N1 qui répond et qui re-transfère au N2... Génial.
Je confirme, j'ai constaté des mêmes problèmes, probablement causé par des caractères non pris en charge.
Depuis, je m'interdis d'utiliser d'autres caractères que ceux listés sur la
doc S3 :
Caractères alphanumériques | Caractères spéciaux |
0-9 a-z A-Z
| ! - _ . * ' ( )
|
Ma conclusion est que la migration risque de faire fuire des clients. Il y a de fortes chances que les clients utilisent cet outil aussi pour aller voir ailleurs (AWS par exemple) surtout quand un service annoncé comme pérenne s’arrête au bout de 4 ans.
Ils auraient clairement du développer un truc pour que la migration se fasse de manière automatisée via l'interface.
Mon point de vue est que le système classic n'était pas pleinement satisfaisant pour scaleway en terme de maintenance. Il ne répondait pas à la demande des pros qui veulent une compatibilité S3.
Malheureusement, ca ressemble à du ovh qui annonce un super truc innovant pour le tuer quelques temps après.
Complètement d'accord !
A titre perso, je préférais C14 Classic. Le principe d'archive, et les multiples protocoles proposés (SCP, FTP ...) m'allaient très bien.
Le seul avantage que je vois à la solution sur base S3, est de pouvoir restaurer un seul fichier (alors que sur C14 Classic, c'était forcément une archive complète). Pour le reste, le passage à la solution sur base S3 ne m'apporte aucun bénéfice, mais plutôt des régressions (forcé d'utiliser un logiciel compatible S3, restriction sur les caractères, inadapté aux petits fichiers).