Re: méthode brute ?

La différenciation sauvegarde/archivage est super saine... Mais elle ne résiste pas à l’UX des personnes pour lesquelles je fais cette sauvegarde.

C'est parce qu'ils n'ont pas compris la différence.
C'est très courant, les utilisateurs (même scientifiques) ne voient pas, ne veulent pas voir, le "côté informatique". Et perso je ne leur jette pas la pierre puisque mon expérience fait que je vois des architecctes qui eux mêmes n'ont aucune conscience des outils et organisation qu'ils inventent, aujourd'hui des gens sont propulsés architectes sans aucune expérience technique de terrain. Bon revenons à nos moutons, ce n'est pas le sujet, il s'agissait juste d'illustrer le fait qu'il est difficile de reprocher quoi que ce soit aux utilisateurs lorsque nos propres collègues ne comprennent pas les enjeux techniques et financiers de leur solutions. Ajoutons à cela bon nombre de gens du métier qui voudraient faire comprendre les tenants et aboutissants de chaque contrainte et solution technique à leurs utilisateurs. Au final, c'est pas gagné :)

Pour faire comprendre il faut illustrer. Pour illustrer il faut des chiffres. Pour faire parler des chiffres il faut parler du besoin. Pour faire parler les utilisateurs de leur besoin il faut poser les bases et leur donner les bons outils d'expression :
a) retour en service
b) quantité
c) durée de conservation

Ça a l'air con comme ça, mais c'est bien le centre de la question : exprimer les contraintes techniques pour ajuster la réponse au besoin. Lorsqu'on annonce clairement que le temps de restauration sera de cinq jours, il faut bien que les utilisateurs comprennent que c'est cinq jours de service sans données disponibles ... Et ça, en général, ils comprennent bien.

Cela permet de poser ensemble le problème mais selon leur vision à eux, qui est générale binaire :
La donnée qui doit être disponible le plus vite possible en cas de restauration.
La donnée qui n'est pas indispensable à un retour rapide de service.

Voilà, on a nos deux ensembles, les deux seuls réellement indispensables. Tout le reste, dessous, c'est du métier, de la tambouille interne.

Au final je dirais bien humblement qu'il faut distinguer non pas deux mais trois différences. Pas seulement la distinction sauvegarde / archivage, mais des différences en terme de date : retour rapide / restauration partielle / restauration complète.

il y a plusieurs cas avec récupération de données assez anciennes.

C'est (je trouve aussi, toujours amha) le second point, une fois le premier correctement posé et expliqué. C'est la date limite de conservation du produit, au delà de laquelle il sera périmé. Et cela permet d'illustrer parfaitement la différence en terme de temps à retour de service.

Au final, cela fait un tableau de ce genre :
les temps à retour attendu de services (retour rapide / restauration partielle / restauration complète)
les estimations de poids nécessaires à ces services.

elles ne le feront pas elles-mêmes

Non, car ce n'est ni leur job ni une nécessité pour eux.
Par contre la gestion de l'archivage est de leur responsabilité. Au final ils doivent faire deux choses :
Désigner initialement ce qui sera sauvegardé (à faire une seule fois au début, puis rarement en cas de modif).
Et gérer ce qui devra être archivé (à faire de manière régulière)
On ne bascule pas une sauvegarde en archive, et on ne sert pas d'un archivage pour des sauvegardes. Les seules personnes à même de savoir ce qui doit être archivé ce sont les utilisateurs. Qu'ils dérapent et que ça ne soit pas parfait n'est pas ton problème, et rien n'est jamais parfait. La sauvegarde c'est toi, l'archivage tu te contente de leur fournir de l'espace et un outil.

tl;dr, un peu blabla, désolé.
et on va laisser de côté le vocabulaire bingoloto du genre "dé-duplication / ré-hydratation de la donnée" ...