Logiciels utilisés :
- Client : Windows 11 Famille, PowerShell 7.6, OpenSSH 9.5p2, Restic 0.19.0
- Serveur : Synology DS213j (DSM v7.1.1)
Ma femme utilise un ordinateur portable sous Windows. Pour elle, l’utilisation de cet outil doit se limiter au strict minimum (elle préfère, de très loin, son smartphone). Autant dire que mes encouragements à mettre en place une procédure de sauvegarde automatique pour éviter de perdre toutes ses données n’ont jamais donné lieu qu’à des… « Mouais, je verrai ça un jour. » À savoir que pendant plusieurs années, la seule sauvegarde qu’elle traînait était une vieille clé USB, solution incertaine au possible.
Désespéré, j’ai fini par entreprendre cette tâche par moi-même, en passant par des solutions diverses qui ont suivi ma propre courbe d’apprentissage dans le domaine. D’abord, sauvegarde régulière sur un disque dur externe. Ensuite, j’ai eu l’idée de tenter de gérer la situation via la solution OneDrive de Microsoft. On ne m’y reprendra plus. Finalement, je suis passé à un logiciel (Perfect Backup) permettant des sauvegardes incrémentales et automatiques. Mais un bug sur une sauvegarde m’en a découragé.
J’ai alors décidé d’aller vers des solutions davantage orientées open source, avec l’idée d’avoir quelque chose de solide et (surtout) automatisable pour pouvoir (enfin) cesser d’y penser. Je vous présente ici les solutions que j’ai construites pour sécuriser les données de ma femme — qu’on appellera désormais ici « Julie ».
Stratégie de sauvegarde#
Tout d’abord, on va rappeler une règle basique de la sauvegarde personnelle. Idéalement, un système de backup sérieux doit suivre la règle du « 3-2-1 » : pour être en sécurité, vos données doivent exister au moins en trois copies, sur au moins deux supports différents, dont l’un au moins se trouve hors site. Pour les données du laptop, j’ai opté pour deux sauvegardes incrémentales complémentaires :
- Une sauvegarde locale sur notre NAS familial (un Synology DS213j).
- Une sauvegarde distante sur Backblaze.com, un stockage en ligne connu de la communauté du logiciel libre, qui propose des tarifs intéressants tout en permettant un accès réseau facilité pour les logiciels de sauvegarde présentés ici.
Pour les logiciels justement, j’ai longuement exploré les options disponibles. Exit les gros GUI gourmands en ressources. Étant allergique au clavier non-bépo de Julie et par souci d’efficacité, je voulais un outil que je puisse administrer à distance depuis mon poste, via une connexion SSH. J’ai alors opté pour les solutions suivantes :
- Restic : un outil en ligne de commande open source à la réputation solide. Disponible nativement sous Windows, il se prête facilement à une automatisation via des scripts PowerShell. Il optimise le stockage grâce à la déduplication de données qui permet des sauvegardes incrémentales. Il intègre également des tests de vérification d’intégrité et permet des restaurations partielles ou totales.
- OpenSSH : pour la communication avec le NAS, ce protocole a été préféré à SMB pour sa parfaite intégration dans mon architecture système basée principalement sur Arch Linux. L’utilisation de SSH présente de nombreux avantages pour la gestion des sauvegardes : absence de montages réseau persistants, suppression des conflits d’identifiants Windows, scripts simplifiés, gestion des erreurs plus claire.
Prérequis#
Les prérequis suivants sont nécessaires pour mener à bien la procédure :
- Sur le NAS :
- Création d’un compte pour Julie (TODO : lien interne)
- Activation et configuration du service SSH (TODO : lien interne)
- Sur le laptop :
- Installation de PowerShell 7, OpenSSH et l’éditeur Micro (TODO : lien interne)
- Optionnel :
- Activation du démon
sshdsur le laptop de Julie et configuration d’un accès SSH pour administrer la machine à distance depuis son poste fixe - Mise en place d’un montage
sshfspour éditer les fichiers du laptop directement depuis le poste de travail avec son éditeur favori (Vim, par exemple)
- Activation du démon
Mise en place de la sauvegarde locale#
Installation de Restic#
Pour installer Restic sur Windows, le plus simple est d’utiliser l’utilitaire de gestion de paquets de Windows, WinGet. On ouvre une instance de PowerShell en mode administrateur puis on installe Restic :
winget install restic.restic --scope machineOn vérifie ensuite que l’exécutable est bien installé et accessible :
restic versionAccès SSH au NAS#
Restic communiquera avec le NAS en passant par une connexion SSH, il faut donc que l’utilisateur Julie ait un accès autorisé. Par ailleurs, il faut que cet accès puisse se faire via une clé SSH, ce qui est obligatoire pour automatiser la sauvegarde.
Création d’une clé SSH#
Pour créer une clé SSH sur le laptop, on ouvre un terminal PowerShell depuis la
session de Julie, on s’assure qu’on est dans le bon dossier (C:\Users\julie)
et on génère la clé :
cd $HOME
ssh-keygen -t ed25519 `
-f .ssh\id_ed25519 `
-N "" `
-C "${env:USERNAME}@${env:COMPUTERNAME}_$(Get-Date -Format yyyy-MM-dd)"On vérifie ensuite que les fichiers ont bien été créés :
ls .sshDans la liste affichée, devraient figurer deux fichiers comme ceux-là :
-a--- 22/05/2026 10:23 419 id_ed25519
-a--- 22/05/2026 10:23 112 id_ed25519.pubCes deux fichiers fonctionnent ensemble :
id_ed25519est la clé privée, qui ne doit jamais sortir de ce dossier.id_ed25519.pubest la clé publique, que l’on installera sur le NAS.
On peut visualiser la clé publique à l’aide d’une simple commande :
cat .ssh\id_ed25519.pubElle doit ressembler à :
ssh-ed25519 AAAARNNzaC1lZDI1OTE5AAAAIPGDQJzIiLkq69g6lb+gpsaWL6VOHtqQbUYaePuTDCJG Julie@laptop_2026-05-22Installation de la clé publique sur le NAS#
On part ici du principe que Julie a un compte sans droits administrateur sur le NAS où on veut installer la clé. Si elle avait un compte administrateur, la procédure serait un peu plus simple, mais on préfère ici envisager le cas le plus difficile (et le plus sécurisé). Comme on dit, qui peut le plus peut le moins.
Normalement, si on a installé proprement notre NAS et qu’on a déjà activé le service SSH, on dispose d’un autre utilisateur qui a déjà un accès SSH opérationnel et qui a les droits d’administration (on va l’appeler « nico »). C’est lui qui va bosser pour ouvrir l’accès à Julie.
Pour les curieux : suis-je vraiment obligé de passer par un autre utilisateur ? C’est relou…
Techniquement non. Mais :
- Je pars du principe que le démon
sshdd’un serveur NAS configuré de manière sécurisée interdit, de préférence, la connexion par mot de passe (PasswordAuthentication nodans/etc/ssh/sshd_config). Dans ce cas, il est inévitable d’utiliser un autre utilisateur ayant déjà un accès, sauf à réactiver temporairement l’authentification par mot de passe. - En plus de cela, par défaut, sur DSM 7.1.1, un utilisateur sans droits
d’administration n’a pas accès à un shell, ce qui lui
interdit d’ouvrir une session SSH interactive. C’est pourquoi de nombreux
tutoriels sur Synology indiquent d’attribuer les droits d’administration à
l’utilisateur concerné. Personnellement, je ne souhaite pas donner ces droits à
tous les membres de la famille. Une autre solution est alors de modifier
manuellement le fichier
/etc/passwdet d’attribuer un shell à Julie. Il faut donc obligatoirement qu’un autre utilisateur (administrateur) se connecte pour modifier ce fichier au préalable. - Bien sûr, si Julie a un compte administrateur et si le serveur SSH autorise
la connexion avec mot de passe, elle peut faire elle-même les manipulations
nécessaires. Elle n’aura alors pas besoin de toucher au fichier
/etc/passwd. Il faut toutefois savoir qu’elle ne pourra pas utiliserssh-copy-id, qui est l’utilitaire normalement prévu pour copier une clé SSH, parce que la version d’OpenSSH utilisée par défaut sur Windows n’intègre pas cet outil. Il lui faudra se connecter par mot de passe et créer le fichierauthorized_keys(voir ci-dessous).
Pour copier la clé sur le NAS, on suit les étapes suivantes :
- On se connecte au serveur (ici :
nas.lan) :
$ ssh nico@nas.lan- On crée un dossier
.sshdans le répertoire personnel de Julie, en considérant que sur le NAS, les dossiershomese trouvent dans/var/services/homes/<user>:
$ cd /var/services/homes/Julie/
$ sudo mkdir -p .ssh- Avec l’éditeur Vim, on crée (ou ouvre, s’il
existe déjà) le fichier
authorized_keys:
$ sudo vim .ssh/authorized_keys- On colle dans le fichier la clé que l’on avait affichée à la fin de la section Création d’une clé. On sauve, on sort.
- Il reste alors à ajuster le propriétaire (avec
chown) et les permissions (avecchmod) du dossier et du fichier (pour des explications sur la signification de ces commandes, voir ici (TODO : lien interne)) :
$ sudo chown -R Julie:users .ssh
$ sudo chmod 700 .ssh
$ sudo chmod 600 .ssh/authorized_keysModification de /etc/passwd#
Par défaut, sur certains NAS Synology (mon DS213j, en tout cas), le fichier
/etc/passwd interdit à un utilisateur non administrateur d’avoir accès à un
shell. Il faut donc modifier ce fichier.
Avant de modifier ce fichier, il vaut mieux en faire une copie de sécurité comme indiqué.
$ sudo cp -a /etc/passwd /etc/passwd.bkp
$ sudo vim /etc/passwdUne fois ce fichier ouvert, on modifie la ligne correspondant à Julie. La ligne ciblée doit ressembler à ceci :
Julie:x:1027:100::/var/services/homes/Julie:/usr/bin/nologinL’ensemble du champ après le dernier deux-point (:) correspond au shell
attribué à Julie. Il faut modifier cette ligne (uniquement !), en remplaçant
/usr/bin/nologin (ou /sbin/nologin, ou /bin/false…) par /bin/sh, pour
obtenir le résultat suivant :
Julie:x:1027:100::/var/services/homes/Julie:/bin/shIl faut faire bien attention à ne rien modifier d’autre dans le fichier. On sauve, on sort.
Test de l’accès SSH#
Une fois toutes les étapes terminées, on teste l’accès depuis le laptop de Julie, via PowerShell :
ssh Julie@nas.lanSi ça passe, on est bon. On peut initialiser le dépôt restic !
Initialisation du dépôt Restic#
Il nous faut maintenant initialiser un dépôt Restic sur le NAS afin d’y stocker nos sauvegardes.
- Depuis notre terminal PowerShell, on commence par créer le dossier qui servira pour le dépôt :
ssh Julie@nas.lan 'mkdir -p ~/restic-backup'- Pour pouvoir agir sur un dépôt, la commande
restica besoin de deux choses : l’adresse du dépôt et un mot de passe. Plutôt que fournir ces deux informations à chaque utilisation derestic, on peut définir deux variables d’environnement : RESTIC_REPOSITORY pour le dépôt, RESTIC_PASSWORD pour le mot de passe. Le plus pratique est de définir ces deux variables dans un script PowerShell qu’il nous suffira d’exécuter une seule fois au début d’une session pour pouvoir utiliser ensuiteresticsans nous en soucier. Ce script servira ensuite aussi lors de la phase d’automatisation. On crée donc un script :
cd $HOME
mkdir .restic
micro .restic\restic_env_local.ps1- Dans ce fichier, on copie le code suivant, en veillant à renseigner correctement l’identifiant et l’adresse du serveur, et en choisissant un mot de passe.
$env:RESTIC_REPOSITORY="sftp:Julie@nas.lan:/home/restic-backup"
$env:RESTIC_PASSWORD="mot-de-passe-au-choix"Pour les curieux : pourquoi /home/restic-backup au lieu de /home/Julie/restic-backup ?
/home/restic-backup au lieu de /home/Julie/restic-backup ?Restic accède au dépôt via le protocole SFTP. Sur DSM 7.1.1, le serveur SFTP
expose le répertoire personnel de l’utilisateur sous la forme d’un dossier
virtuel /home. Le chemin /home/restic-backup correspond donc au dossier
restic-backup situé dans le répertoire personnel de Julie.
Le mot de passe du dépôt Restic est indispensable pour accéder aux sauvegardes. Si vous le perdez, les données du dépôt deviendront irrécupérables.
- On peut maintenant initialiser le dépôt, en chargeant d’abord notre script :
. $HOME\.restic\restic_env_local.ps1
restic initPremière sauvegarde#
Avant de lancer une première sauvegarde, quelques explications s’imposent sur le fonctionnement de Restic.
Contrairement à une simple copie de fichiers, Restic fonctionne par snapshots, c’est-à-dire qu’il réalise un instantané de vos données à un instant donné. Chaque nouvelle sauvegarde ne transfère ensuite que les données nouvelles ou modifiées, ce qui permet de réaliser des sauvegardes incrémentales. On bénéficie ainsi d’un historique complet des sauvegardes tout en limitant fortement l’espace disque utilisé et le volume de données transférées. La première sauvegarde est donc généralement beaucoup plus longue que les suivantes, puisque l’ensemble des données doit être copié une première fois.
Il faut savoir également que lors d’une sauvegarde d’un dossier personnel comme
C:\Users\julie, restic est parfois dans l’impossibilité d’accéder à certains
fichiers verrouillés (fichiers de cache et bases de données temporaires utilisés
par des processus en cours). On peut résoudre ce problème à l’aide de l’option
--use-fs-snapshot, qui permet à restic d’utiliser le service VSS de Windows
pour obtenir un instantané cohérent des fichiers à sauvegarder. À noter que
cette option impose d’utiliser un shell en mode
administrateur.
En complément, on exclut quelques dossiers à l’aide de l’option --exclude :
- Le dossier
$HOME\AppData\Local\Temp, qui ne contient que des données temporaires sans intérêt pour une restauration. - Le dossier
$HOME\AppData\Local\Microsoft\WindowsApps, qui contient principalement des alias et fichiers spéciaux recréés automatiquement par Windows, et queresticn’est pas capable de sauvegarder.
L’usage de ces options permet d’obtenir une sauvegarde sans avertissements sur
le poste de Julie. Il est cependant possible que sur un autre poste, restic
signale des alertes sur d’autres fichiers spécifiques. Si cela se produit,
rassurez-vous : ces avertissements n’empêchent pas la sauvegarde de se terminer
correctement. Ils s’avèrent même utiles au début pour repérer les dossiers
résiduels et peaufiner ses filtres avant d’automatiser la procédure.
Dans le doute, on peut tester la commande restic en ajoutant l’option
--dry-run, qui permet de voir la commande en action sans qu’elle ne touche
vraiment aux fichiers.
Ceci étant dit, pour procéder à une première sauvegarde, on ouvre un terminal
PowerShell en mode administrateur, on recharge les variables d’environnement et
on exécute restic backup :
. $HOME\.restic\restic_env_local.ps1
restic backup $HOME `
--use-fs-snapshot `
--exclude "$HOME\AppData\Local\Temp" `
--exclude "$HOME\AppData\Local\Microsoft\WindowsApps"Si tout va bien, en fin de procédure la commande devrait afficher un compte-rendu se terminant par :
processed 116513 files, 26.537 GiB in 46:18
snapshot c5391e78 savedSi on veut vraiment en avoir le cœur net, on peut utiliser la commande restic snapshots, qui donne la liste des sauvegardes effectuées :
repository 7246e2ee opened (version 2, compression level auto)
ID Time Host Tags Paths Size
----------------------------------------------------------------------------------
c5391e78 2026-06-04 13:48:44 jlaptop-av C:\Users\julie 26.537 GiB
----------------------------------------------------------------------------------
1 snapshotsAutomatisation des sauvegardes locales#
Création d’un script de sauvegarde#
Pour automatiser une sauvegarde via Restic dans Windows, il nous faut d’abord créer un script PowerShell de sauvegarde :
cd $HOME\.restic
micro restic_backup_local.ps1Voilà un modèle minimal de script que vous pouvez reprendre, améliorer et peaufiner à l’aide de la documentation Restic :
# Initialize environment
. $HOME\.restic\restic_env_local.ps1
# Backup
restic backup $HOME `
--use-fs-snapshot `
--exclude "$HOME\AppData\Local\Temp" `
--exclude "$HOME\AppData\Local\Microsoft\WindowsApps"
# Apply retention policy
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneLe script commence par charger les variables d’environnement nécessaires pour
que Restic travaille avec le bon répertoire, avant de procéder à une sauvegarde
à l’aide de la commande restic backup.
Ensuite, il utilise la commande restic forget afin de supprimer les anciens
snapshots du dépôt. L’option --prune permet de supprimer aussi les données
associées, elle est donc nécessaire pour libérer l’espace disque occupé par les
anciennes sauvegardes.
Comment définir l’ancienneté des données conservées ?
La commande proposée dans le script conserve une sauvegarde pour chacun des derniers 7 jours, une pour chacune des 4 semaines précédant les 7 jours et une pour chacun des 6 mois précédant les 4 semaines. Vous pouvez adapter la politique de suppression des anciennes sauvegardes à l’aide des règles suivantes :
--keep-daily <X>: Conserve une sauvegarde journalière pendant les derniersXjours.--keep-weekly <Y>: Conserve une sauvegarde hebdomadaire pendant les dernièresYsemaines.--keep-monthly <Z>: Conserve une sauvegarde mensuelle pendant les derniersZmois.- Vous pouvez même ajouter une règle pour des sauvegardes annuelles
(
--keep-yearly) ou peaufiner davantage à l’aide des nombreuses options disponibles. - À noter que ces règles sont cumulatives. Avec la politique proposée, Restic conserve les sauvegardes des 7 derniers jours, puis 4 sauvegardes hebdomadaires plus anciennes, puis encore 6 sauvegardes mensuelles.
Création d’un script d’automatisation#
Pour automatiser la sauvegarde Restic sous Windows, nous écrivons un script PowerShell chargé d’enregistrer la tâche dans le Planificateur de tâches Windows (Task Scheduler) :
cd $HOME\.restic
micro install_sched_task_local.ps1Voilà un exemple de script permettant d’automatiser la tâche :
$Script = "$HOME\.restic\restic_backup_local.ps1"
$Action = New-ScheduledTaskAction `
-Execute "pwsh.exe" `
-Argument "-NoProfile -ExecutionPolicy Bypass -File `"$Script`""
$Trigger = New-ScheduledTaskTrigger `
-Daily `
-At 21:00
$Principal = New-ScheduledTaskPrincipal `
-UserId "$env:USERNAME" `
-LogonType S4U `
-RunLevel Highest
$Settings = New-ScheduledTaskSettingsSet `
-AllowStartIfOnBatteries `
-DontStopIfGoingOnBatteries `
-StartWhenAvailable `
-ExecutionTimeLimit (New-TimeSpan -Hours 4)
Register-ScheduledTask `
-TaskName "ResticBackupLocal" `
-Action $Action `
-Trigger $Trigger `
-Principal $Principal `
-Settings $Settings `
-Description "Daily Restic backup to NAS"Ce script crée une tâche automatisée qui exécute restic_backup_local.ps1 chaque jour
à 21h00. Quelques remarques sur les choix de ce script :
- Le mode
S4Upermet à la tâche de s’exécuter avec les droits de l’utilisateur sans stocker son mot de passe. La tâche continue donc de fonctionner même si l’utilisateur modifie son mot de passe. - La sauvegarde se produit aussi bien lorsque le laptop est alimenté par secteur
que par batterie (
-AllowStartIfOnBatterieset-DontStopIfGoingOnBatteries). Cela peut être modifié si on souhaite économiser au maximum l’utilisation de la batterie. En les supprimant, Windows n’exécutera la tâche que lorsque l’ordinateur sera alimenté sur secteur. - Dans tous les cas, l’option
-StartWhenAvailablegarantit que la sauvegarde se fasse dès que possible dans le cas où l’état du laptop ne le permettait pas auparavant (si, notamment, il était éteint). - Le processus de sauvegarde ne peut excéder une durée de 4 heures
(
-ExecutionTimeLimit (New-TimeSpan -Hours 4)) afin d’éviter d’avoir un processus bloqué indéfiniment dans le cas où il y aurait un problème. Cette limite est très largement suffisante sur le poste de Julie puisque la première sauvegarde (la seule qui copie l’ensemble des données) a duré environ 45m pour 26Go. Bien sûr, elle peut être adaptée selon les configurations techniques.
Activation de la tâche planifiée#
Pour enregistrer la nouvelle tâche dans le Planificateur Windows à partir du script, il suffit d’exécuter ce dernier dans PowerShell (mode administrateur) :
cd $HOME\.restic
.\install_sched_task_local.ps1On peut ensuite vérifier que le script est bien enregistré à l’aide de :
Get-ScheduledTask -TaskName ResticBackupLocalOn peut également tester un lancement immédiat de la tâche :
Start-ScheduledTask -TaskName ResticBackupLocalLa sauvegarde s’exécute en arrière-plan. Une fois la tâche terminée (ce qui peut prendre quelques dizaines de secondes ou davantage selon le volume de données), on peut vérifier l’état du dernier run de la tâche :
Get-ScheduledTaskInfo -TaskName ResticBackupLocalCe qui retournera un résultat de ce type :
LastRunTime : 07/06/2026 22:26:49
LastTaskResult : 0
NextRunTime : 08/06/2026 21:00:00
NumberOfMissedRuns : 0
TaskName : ResticBackup
TaskPath :
PSComputerName : Ici, LastRunTime nous permet de confirmer que la tâche vient effectivement
d’être accomplie et la valeur de LastTaskResult (=0) confirme que le processus
s’est terminé sans erreurs. À noter que si cette dernière valeur renvoie 267009,
cela signifie que la tâche est toujours en cours d’exécution. Enfin,
NextRunTime montre que la prochaine occurrence interviendra à 21h00 le jour
suivant, ce qui est cohérent avec la politique définie.
À ce point, autant jeter un œil à l’état du dépôt via restic snapshots :
repository 7246e2ee opened (version 2, compression level auto)
ID Time Host Tags Paths Size
----------------------------------------------------------------------------------
c5391e78 2026-06-04 13:48:44 jlaptop-av C:\Users\julie 26.537 GiB
7784e7dc 2026-06-07 22:26:49 jlaptop-av C:\Users\julie 26.698 GiB
----------------------------------------------------------------------------------
2 snapshotsBOOM !
Tout va bien, voilà un nouveau snapshot qui vient s’ajouter au précédent. En
comparant les valeurs de la colonne Size, on constate que le second snapshot
contient environ 160 Mo de données supplémentaires par rapport au premier. Cela
correspond aux fichiers ajoutés ou modifiés entre les deux sauvegardes.
Pour les curieux qui veulent vérifier que les données sont bien là !
La présence d’un snapshot est déjà un excellent indicateur, mais il est possible d’aller plus loin avec quelques commandes simples permettant d’afficher le contenu des sauvegardes :
restic ls c5391e78: Pour parcourir le contenu du snapshotc5391e78.restic ls latest: Pour parcourir le contenu du dernier snapshot.restic find "exemple.txt" --snapshot latest: Pour vérifier la présence ou chercher le chemin complet du fichierexemple.txt.restic find "\C\Users\julie\Documents" --snapshot latest: Pour vérifier le contenu du dossier personnelDocuments.
On peut bien sûr aussi immédiatement tester une restauration totale des données vers un dossier de test de la manière suivante :
cd $HOME
mkdir restore-test
restic restore latest --target restore-testPlus simplement, on peut aussi juste tenter de restaurer un dossier ou un
fichier en ajoutant l’option --include :
restic restore latest `
--target restore-test `
--include "/C/Users/julie/Documents/blabla/blibli.PDF"Notez que cette opération restaure dans $HOME\restore-test\ l’arborescence
complète du fichier (C:\Users\julie\Documents\blabla\blibli.PDF), tout en
préservant les attributs des fichiers et dossiers. Il se trouve que certains de
ces dossiers ont l’attribut readonly (c’est le cas de Users\ et
Documents\). Pour effacer tout le dossier de test sans difficultés on peut
utiliser :
Remove-Item $HOME\restore-test\ -Recurse -ForceRenforcer la sécurité : la sauvegarde distante#
Il est maintenant temps de mettre en place une sauvegarde complémentaire vers un stockage distant, ce qui permettra de mieux sécuriser les données de Julie.
Création du dépôt#
Bien sûr, il nous faut avant tout ouvrir un compte sur un site de stockage en ligne (par exemple OVH, IDrive ou Scaleway). Je propose ici une procédure basée sur l’offre B2 de Backblaze.com, choisie pour les raisons exposées plus haut. Il vous faut bien sûr adapter la procédure qui suit à l’hébergeur que vous avez retenu.
Une fois ouvert un compte, la première chose à faire est de créer un « bucket » pour les sauvegardes en allant dans la section Buckets et en cliquant sur « Create a Bucket ». Pour cette utilisation, les options par défaut conviennent :

Ensuite, nous créons une clé d’accès dédiée à Restic. Pour cela, il faut aller dans la section « Application Keys » du menu de gauche, puis sélectionner « Add a new Application Key ». On veille à associer la clé au bucket ciblé :

Au bout du processus, Backblaze affichera une « keyID » et « ApplicationKey ». Ils ne seront affichés qu’une seule fois à la création, il est donc important de les noter ou sauvegarder dans votre gestionnaire de mots de passe préféré.
On peut ensuite créer un nouveau script permettant de charger les variables d’environnement Restic pour le dépôt Backblaze, sur le même principe que pour le NAS :
cd $HOME
micro .restic\restic_env_remote.ps1Dans ce fichier, on copie le code suivant, en veillant à renseigner le nom du «
bucket » (ici jlaptop-restic) et les valeurs de keyID et ApplicationKey
(qui permettent à Restic d’accéder à Backblaze), qui sont à affecter
respectivement aux variables B2_ACCOUNT_ID et B2_ACCOUNT_KEY. Enfin, on
choisit un mot de passe destiné à chiffrer le dépôt Restic (RESTIC_PASSWORD) :
$env:RESTIC_REPOSITORY = "b2:jlaptop-restic"
$env:B2_ACCOUNT_ID = "004e84f858838cf0000000003"
$env:B2_ACCOUNT_KEY = "K003duGzV03UdZRx5KmcrhQV8pdgxFB"
$env:RESTIC_PASSWORD = "mot-de-passe-au-choix"Initialisation du dépôt#
Pour l’initialisation du dépôt, on continue de suivre la procédure définie pour le NAS. On charge d’abord notre script :
. $HOME\.restic\restic_env_remote.ps1
restic initOn peut alors lancer une première sauvegarde depuis un terminal PowerShell
ouvert en mode administrateur. On exécute restic backup avec les options qui
vont bien et que nous avions déjà discutées ici :
restic backup $HOME `
--use-fs-snapshot `
--exclude "$HOME\AppData\Local\Temp" `
--exclude "$HOME\AppData\Local\Microsoft\WindowsApps"On vérifie enfin qu’on a bien un nouveau snapshot :
restic snapshotsAutomatisation de la sauvegarde#
Pour automatiser une sauvegarde vers Backblaze avec Restic, on reprend là aussi la procédure déjà suivie avec quelques adaptations. Il nous faut d’abord créer un script PowerShell de sauvegarde :
cd $HOME\.restic
micro restic_backup_remote.ps1Voilà un modèle minimal que vous pouvez adapter à vos besoins :
# Initialize environment
. $HOME\.restic\restic_env_remote.ps1
# Backup
restic backup $HOME `
--use-fs-snapshot `
--exclude "$HOME\AppData\Local\Temp" `
--exclude "$HOME\AppData\Local\Microsoft\WindowsApps"
# Apply retention policy
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneNous écrivons ensuite le script PowerShell chargé d’enregistrer la tâche dans le Planificateur de tâches :
micro install_sched_task_remote.ps1Voilà un exemple de script permettant d’automatiser la tâche :
$Script = "$HOME\.restic\restic_backup_remote.ps1"
$Action = New-ScheduledTaskAction `
-Execute "pwsh.exe" `
-Argument "-NoProfile -ExecutionPolicy Bypass -File `"$Script`""
$Trigger = New-ScheduledTaskTrigger `
-Daily `
-At 22:00
$Principal = New-ScheduledTaskPrincipal `
-UserId "$env:USERNAME" `
-LogonType S4U `
-RunLevel Highest
$Settings = New-ScheduledTaskSettingsSet `
-AllowStartIfOnBatteries `
-DontStopIfGoingOnBatteries `
-StartWhenAvailable `
-ExecutionTimeLimit (New-TimeSpan -Hours 4)
Register-ScheduledTask `
-TaskName "ResticBackupRemote" `
-Action $Action `
-Trigger $Trigger `
-Principal $Principal `
-Settings $Settings `
-Description "Daily Restic backup to remote storage"Ce script reprend la logique du précédent script de sauvegarde mais décale le processus à 22h afin d’éviter que les deux sauvegardes ne s’exécutent simultanément.
Une fois le script préparé, on enregistre la nouvelle tâche dans le Planificateur via PowerShell en mode administrateur :
.\install_sched_task_remote.ps1On vérifie que le script est bien enregistré :
Get-ScheduledTask -TaskName ResticBackupRemoteOn teste un lancement immédiat de la tâche :
Start-ScheduledTask -TaskName ResticBackupRemoteComme précédemment, on fait quelques vérifications d’usage via ces deux commandes :
Get-ScheduledTaskInfo -TaskName ResticBackupRemote
restic snapshotsEt hop ! Désormais, nous disposons d’une seconde sauvegarde vers un stockage distant, ce qui ajoute une couche de sécurité supplémentaire aux données de Julie.