Accéder au contenu principal

Sauvegarde via rsync sur un nas Synology DS220+

 

Introduction

L'article présentera la sauvegarde du répertoire home d'un disque en btrfs sur un NAS Synology DS220+ à l'aide de rsynch

La configuration par défaut a été utilisé pour installer la  distribution OpenSUSE Tumbleweed.Le SSD est donc formaté en BTRFS. 

Activer rsync 

Dans l'interface web de Synology, il faut s'assurer que le service rsync est activé. De plus, puisqu'on lance le rsync depuis un utilisateur externe, il faut aussi activé le rsync account.


Commande rsync

Il sera assumé qu'un utilisateur rsync_userr avec le mot de passe 1234 existe sur le NAS et qu'il est alloué d'utiliser rsync. Ce droit lui peux lui être octroyé dans l'onglet application en éditant un utilisateur.

19.23.31.115 étant l'adresse de votre NAS.

collinm étant le nom de votre utilisateur local.

rsync --progress -avr  --delete --exclude="lost+found" --exclude=".cache" /home/collinm ssh rsync_user@19.23.31.115::Backup/rsync

Cette commande synchronisera votre home local dans le répertoire rsync du disque nommé Backup. A modifier selon votre configuration.

Cette sommande vous demandera de taper votre mot de passe.

rsync sans mot de passe

La commande précédente fonctionne, cependant si vous désirez lancer cette commande automatiquement, cela n'est pas pratique de devoir entrer le mot de passe à chaque fois.

Il existe une méthode simple, mais pas des plus sécuritaire est d'utiliser sshpass.

Il s'agira d'inscrire le mot de passe qui sera passé à rsync par la suite

sshpass -p 'Double2015' rsync --progress -avr  --delete --exclude="lost+found" --exclude=".cache" /home/collinm ssh rsync_user@19.23.31.115::Backup/rsync

Cette commande pourrait être ajouté dans un script bash et lancé automatiquement par cron.

Ce n'est pas sécuritaire, mais cela pourrais être acceptable si c'est pour une utilisation domestique avec aucune autre personne que vous sur votre réseau.

Autrement je vous conseille d'opter pour la création d'une clé ssh.

Commentaires

Posts les plus consultés de ce blog

Toshiba AC100 et Android 4

Toshiba AC100 est un smartbook. Toshiba est la seule grosse entreprise qui a commercialisé un smartbook, malgré que plusieurs autres en aient présenté. Un smartbook est similaire à un netbook (taille) en plus d'avoir des caractéristiques souvent proche à un mobile (GPS, 3g, processeur ARM, autonomie). Le Toshiba AC100 utilisait le système d'exploitation Android en version 2.1. Toshiba a effectué une mise à jour Android 2.2. Il a arrêté la commercialisation et le support de cette machine. L'appareil ayant un bon rapport qualité/prix, la communauté le prit en charge. Il est possible d'installer une version beaucoup plus récente d'Android telle que la 4.1. La rom alternative Cyanogen a été utilisée pour ce portage. Les procédures citées ont été faites sous Linux.  Sous Windows, il faut télécharger une version de nvflash pour ce système. Préparation Télécharger les fichiers: cm_ac100-ota-eng.cm10-beta2.zombah.zip recovery.ac100-cm10_beta2.img via ce...

Spring data jpa et Hibernate’s Warning “firstResult/maxResults specified with collection fetch”

Nous verrons dans cet article comment corrigé le problème  Hibernate’s Warning “firstResult/maxResults specified with collection fetch” qui peut survenir lorsqu'il y a un fetch d'effectuer et qu'il y a du paging. Nous utiliserons spring data jpa. Détail structure Imaginons une relation 1 à plusieurs Lorsqu'on obtient un parent, on désire obtenir aussi sa liste d'enfants. En sql, il y aurait une jointure à effectuer. Il est question d'une recherche avancé où on pourrait recherche par plusieurs critères. Spécification Création d'une spécification pour construire une requête dynamique @Component public class ParentSpecification {     public Specification<Parent> recherche(RechercheParent recherche) {         return (root, cq, cb) -> {             Join<Parent, enfant> enfantJoin;              List<Predicate> rootPredicates = new ArrayList<>();       ...

Migration d’une application Spring Boot 2.2 vers Spring Boot 4.0 : retour d’expérience concret

 En 2019, nous avons développé une application métier basée sur : Java 8 Spring Boot 2.2.7 Gradle 6.6.1 Thymeleaf Bootstrap 4.3.1 Environ 40 000 lignes de code Java Fin 2025, voici un retour d’expérience concret sur la migration vers : Java 25 Spring Boot 4.0.1 Gradle 9.2.1 La partie thymeleaf, n'a pas été touché, il y a quelques warning concernant l'obsolescence de certain commande tel que th:include. Une migration plus rapide que prévu Un point important : en moins de 30 minutes, l’application démarrait sur la nouvelle stack. Évidemment, "ça démarre" ne veut pas dire "tout fonctionne", mais ce premier jalon est très révélateur : la base Spring Boot reste solide les outils de migration sont matures la dette technique était maîtrisée Les changements majeurs rencontrés De javax.* à jakarta.* C’est probablement le changement le plus visible. Tous les imports javax.* doivent être migrés ve...