Psychofox a écrit 10742 commentaires

Je crois que c'est le gars qui trolle via le site debian.community (qui n'a rien à voir réellement avec debian, à part vouloir leur nuir).

ah ben du coup merci de me faire découvrir dqlite ! Il est peut-être plus robuste je vais voir ça.

Le pire c'est que j'ai du utiliser dqlite sans m'en souvenir dans le passé…via des cluster k3s.

…on en revient à n'accepter des appels que depuis nos contacts sur nos téléphones personnels.

Je n'ai personnellement jamais compris l'intérêt de la classe APIPA.

Je ne crois pas que la fonctionnalité existe mais si j'avais besoin je ferais ça depuis un vps avec minio ou rclone.

C'est un choix à faire en fonction de l'investissement.

Dans le cas de Wasabi, j'imagine que si j'ai une destruction locale totale je ferais une synchro du bucket vers un bucket dans un autre datacenter avant de rapatrier toutes les données. C'est relativement vite fait.

Personnellement je pense que le point le plus important avant d'avoir n copies c'est de vérifier régulièrement l'intégrité des données sur l'unique sauvegarde hors-site, chose que j'avoue n'avoir pas encore automatisé. Parce que bon synchroniser sur 3 sites différents des fichiers corrompus, ça a peu d'intérêt.

Ben l'idée c'est justement que tu n'utilises pas impress ou powerpoint mais ton éditeur de texte/code favori.

Et il y a plein de frameworks conçus pour aider ceux qui ne parlent pas couramment le html:

https://gist.github.com/johnloy/27dd124ad40e210e91c70dd1c24ac8c8

Je pars du principe que je peux tout perdre du jour au lendemain. Domicile qui brûle, tremblement de terre, tsunami, que sais-je :)

Si j'ai une copie dans un autre pays c'est pour pallier à ce genre de merde.

Alors certe au début je n'aurais surtout besoin que des papiers administratifs et pas de ma collection de photos et souvenirs de ces 20 dernières années qui peuvent attendre un peu plus. Mais je dois aussi penser qu'une fois que j'ai tout perdu, ma copie unique est celle externalisée, donc j'ai tout intérêt à récupérer toutes les données et en avoir une copie locale. On sait jamais qu'un coup de loi de murphy fait qu'ils aient eux-même des problèmes ou qu'un problème de facturation fait qu'ils te dégomment tes données.

Je ne comprends d'ailleurs pas cet engouement récent pour medium. Ça apporte quoi réellement ce truc à part centraliser du bordel sur une plateforme ?

Ça ne change pas que si ça prend 3 semaines à copier, c'est bien plus chiant que de se faire livrer des disques en 2-3 jours ouvrables. Et accessoirement si tu es dans un cas de disaster recovery avec perte totale, ton environnement local tu l'as pas et dois le reconstruire d'abord en achetant du matériel. Ça ralentit d'autant plus la démarche (et faut avoir penser à garder ses secrets, comme les clés de chiffrements, accessibles ailleurs que sur le backup our l'environnement à reconstruire.

Je crois que crashplan et backblaze ont un service d'envoi de disques, moyennant une modique somme, mais la dernière fois que j'avais vérifié c'était valable uniquement aux USA.

Je suis le seul à trouver à peu près inutilisable l'appli nextcloud sur android?

Alors oui elle synchronize mes photos et vidéos mais plus ou moins quand ça lui chante et l'appli se fige bien souvent quand on veut la consulter.

Ce qui compte c'est la bande passante. Pour récupérer les données tu renvoies Thomas ou ses futurs collègues.

Je ne dis pas que ça n'existe pas (quand j'en avais 20 il y avait un ancien coureur pro italien qui faisait encore ses 80km par jour à 92ans en vallée de chevreuse) mais ils n'ont pour la plupart pas commencé à 60ans!

J'utilise restic (et duplicati sur le windows de ma copine) sur du stockage objet wasabi.

Le tout est chiffré.

Il y a quelques années j'avais utilisé crashplan quand ils avaient une offre particulier similaire à backblaze. Les backups/restore entre appareils locaux étaient très efficace mais un jour j'ai testé restaurer 1TB depuis leurs serveurs, les temps de download étaient à des années lumières de leurs temps d'upload si bien que ça aurait pris plusieurs semaines de copie continues. Inutilisable en cas de désastre donc

Bref testez vos temps de restauration, ça peut être important si un jour vous souffrez d'un incendie ou grosse perte de données.

Le pdf c'est merdique pour autre chose qu'un truc qui a vocation d'être imprimé. Vous connaissez beaucoup de présentations qui finissent imprimées?

On a inventé un truc pratique qui permet d'avoir du contenu lisible sur des appareils de tout type de taille d'écran, qui permet de jouer différents types de contenu multimédia, sur lequel on peut même jouer l'audio voire la vidéo de présentation. Ça s'appelle HTML5 (+css). C'est bien plus pratique qu'un pdf ou une vidéo sur youtube et ça se partage facilement.

Et je ne suis pas un excité du javascript, mais c'est bien un cas d'usage ou un peu de javascript peut aussi aider sans le rendre obligatoire.

Il me semble que tu bottes en touche. Si tu as besoin d'écrire un script spécifique pour que backuppc trouve les données à ingérer, c'est que t'as besoin de faire de même pour recopier les données au bon endroit quand tu restaure…Ton script ne rend pas backuppc omniscient.

Un backup, une fois fait, tu peux (et même doit) le tester. Ton snap, non, à moins de le remonter. Mais si tu le remontes, c'est que tu as un souci, et si tu as un souci lorsque tu le remontes, il est trop tard pour faire une sauvegarde.

Qu'est-ce que tu entends par "le remonter"

Pour tester une sauvegarde, on restore les données, quelque soit la manière de faire une sauvegarde. Et si la BD est stoppée, si c'est fiable.

Et un admin compétent ne coupera jamais une BD 5s le temps de faire le backup alors qu'il existe nativement la possibilité de le faire sans.

Tout dépend de l'utilisation. Pour une BD avec n accès concurrents à toute heure de la journée et pas de lien vers des données sur des fichiers "traditionnels" oui je suis d'accord.

Pour une BD utilisée par une seule application, avec une foultitude de lien vers des fichiers attachés, stopper l'application et et faire un snapshot du volume où sont stocké les fichier est la meilleure manière d'avoir une cohérence entre BD et fichiers attaché. Si on fait ça quite à stopper l'appli on peut aussi décider de stopper la BD et la sauvegarder de la même façon si par exemple ça fait économiser le prix d'une licence pour un connecteur de base de donnée du logiciel de backup ou accélère le temps de restauration des fichiers.

Cela permet de fournir une autre manière d'avoir des backups automatisés pour les SGBD, où sauvegarder directement les fichiers est une TRES mauvaise idée.

Ça dépend de la granularité de récupération que tu veux avoir.

Si tu veux pouvoir restaurer une db/une table ou quelques lignes effectivement c'est nul.

Si tu veux juste du disaster recovery pour pallier à des gros crashes, c'est plus rapide de couper 5 secondes, faire un snap et relancer et faire un backup du snap.

Tout dépend en fait si c'est une db partagée par des applis/clients multiples ou si c'est juste une db embarquée avec une appli métier.

…c'est qu'en est-il de l'intégration avec libreoffice?

Oubliez mon dernier point qui n'est valide qu'avec certains pilotes de stockage et pas le projet docker lui-même.

Suis-je le seul supris de voir un projet avec un script de backup et absolument rien pour décrire le process de restoration des données?

Soit dit en passant GLPI est le cas typique d'une appli qui peut souffrir de quelques secondes d'arrêt chaque nuit et pour laquelle il y a peu de chance de vouloir restaurer seulement quelques lignes ou une table. Et ils semble que les volumes semblent être des bind mounts de répertoires de la machine hôte.

Du coup pourquoi ne pas faire plus simple:
1. docker-compose stop
2. snapshot des volumes et montage sur un autre point de montage sur l'hôte
3. docker-compose up
4. backup des snapshots
5. cleanup des snapshots (peut aussi être réalisé en début de point 2 si on peut supporter d'avoir l'espace utilisé et qu'on veut une copie locale de restauration pour des petites bévues)

L'avantage c'est qu'il n'y a quasi aucun scripting, que t'es absolument sûr que le volume de ta db et du reste de l'appli sont cohérents. Avec ta méthode je ne vois rien qui garantie la cohérence entre le dump mysql et les fichiers copiés. Donc à la restauration tu peux te retrouver avec des fichiers uploadés qui ne sont pas référencés en DB et avoir des trucs pas propres..

Et pour le restore ce serait aussi très simple:
- docker-compose stop
- restoration des données dans le point de montage désiré
- docker-compose up

Du reste en utilisant des vrais volumes plutôt que des bind mounts tu pourrais bénéfichier des capacités de snapshots de docker et faire des backups sur des clones.

Dans les faits t'as tout intérêt à mettre les données dans des volumes séparés des conteneurs car quand tu changes d'image (cas typique de mise à jour), tu remplaces le conteneur par un nouveau.

il peut ou pas impliquer sa hiérarchie dans la publication du code, et si non, il met la licence qu'il veut. Évidemment, dans ce cas, la légalité de la licence est discutable.

Hmmm je ne suis pas juriste mais je doute que le fais qu'un employé fasse une erreur rende la distance non valable/illégale. L'employé en question va avoir des problèmes, pourrait probablement être poursuivi en justice aussi, mais ça n'en terni pas ce qui a été publié.

C'est comme si un employé d'une entreprise vend un produit ou signe un contrat de service à une autre entité. Si son employeur n'était pas d'accord, le produit ne peut pas être retiré au client. Le service rendu ne peut pas être inversé, tout au plus on peut l'interrompre et encore si un contrat est signé avec une date finale probablement pas.

Donc à vue de nez si la licence reste légale et le seul recourt que peut avoir l'employeur c'est de changer la licence pour les futures versions. Et si entre temps il y a eu des contributions externe pour changer la licence il devrait repartir d'une version avant publication ou nettoyer tout le code des contribs externes avant de rechanger la licence.

D’où l'importance aussi du vent dans l'équation. Suivant sa direction, il peut casser le peloton, et provoquer des sous groupe favorisant les échappées. C'est les fameuses bordures

Les bordures c'est pas seulement l'effet du vent. C'est l'association du vent de côté avec la nature égoiste de l'être humain.

Pas besoin de vélo couché ou vélomobile pour aller plus vite que 20-25. Avec un peu d'entrainement et une position adaptée ce n'est pas bien dur de rouler à 30-35 (pour les moins de 60ans j'entends).

Mais sinon vous êtes un peu d'accord. Le VAE non immatriculé, ça sert essentiellement pour aller doucement ou circuler en zones vallonées mais c'est franchement désagréable pour aller vite sur le plat, d'autant plus pour les modèles à assistances chinoises dont la coupure d'assistance n'est pas du tout progressive*.

* bon eux sont débridables sans difficulté via un menu à peine caché donc tout le monde les utilise au dessus des 25km/h autorisé, comme les bonne vieilles mobylettes en somme.

J'ai rapidement été voir et c'est quand même un jolie sac dans le répertoire /var/lib/docker/overlay2. Il y a autant de répertoires que de volumes et comme ça il est difficile de savoir qui appartient à qui. Sans compter les volumes fantômes qui peuvent exister.

En général c'est pas ça qu'on fait. On monte le même volume dans un nouveau container qui fait le copie de backup.