On devrait backuper/restaurer les données et construire/reconstruire une VM en infra as code.
Les backups ou snapshots intégrales de VM peuvent faire partis de processus automatisés. Par exemple pour un worlflow d'upgrade automatique de VM, avec rollback automatique en cas de problème, c'est plus rapide et facile à mettre en place de faire le rollback avec un snapshot ou un backup intégral qu'avec un redéploiement complet de la VM. D'autant plus que les backups intégrales et snapshots ne prennent plus tant de place que ca et sont assez rapide, c'est que du delta (à part le premier backup). Généralement, pour les VM utilisant beaucoup de stockage, ce sont les data applicatives qui prennent le plus de place dans les volumes, pas l'OS. Bien sûr, ca se discute selon les cas, et également selon le niveau de backup.
Par contre pour du barmetal, je serais plutôt d'accord avec toi. Ce sont pas les mêmes contraintes, ni les mêmes usages.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Vous refusez
Posté par Astaoth . En réponse au journal Le piège du backup Windows... que je me suis fait tout seul. Évalué à 2.
Les backups ou snapshots intégrales de VM peuvent faire partis de processus automatisés. Par exemple pour un worlflow d'upgrade automatique de VM, avec rollback automatique en cas de problème, c'est plus rapide et facile à mettre en place de faire le rollback avec un snapshot ou un backup intégral qu'avec un redéploiement complet de la VM. D'autant plus que les backups intégrales et snapshots ne prennent plus tant de place que ca et sont assez rapide, c'est que du delta (à part le premier backup). Généralement, pour les VM utilisant beaucoup de stockage, ce sont les data applicatives qui prennent le plus de place dans les volumes, pas l'OS. Bien sûr, ca se discute selon les cas, et également selon le niveau de backup.
Par contre pour du barmetal, je serais plutôt d'accord avec toi. Ce sont pas les mêmes contraintes, ni les mêmes usages.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.