Aller au contenu

Sauvegarde Dossier "surveillance" Vers Google Drive


macandnews

Messages recommandés

Bonjour,

Merci pour les infos. Pour la synchro, je n'avais pas remarqué ce problème avec l'utilisation de la commande rsync. Il y a, semble-t-il, un problème avec le processus de CloudSync. Il faudrait tenter un redémarrage du Syno et voir si le problème se reproduit. Il est vrai que je n'ai pas testé très longtemps cette possibilité et que j'ai adopté le script qui me construit des archives zip synchronisées avec Google Drive. Si vous optez pour cette solution, il faudra adapter le script en tenant compte qu'il n'y a qu'une caméra et que les enregistrements sont au format mp4.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Merci pour les infos. Pour la synchro, je n'avais pas remarqué ce problème avec l'utilisation de la commande rsync. Il y a, semble-t-il, un problème avec le processus de CloudSync. Il faudrait tenter un redémarrage du Syno et voir si le problème se reproduit. Il est vrai que je n'ai pas testé très longtemps cette possibilité et que j'ai adopté le script qui me construit des archives zip synchronisées avec Google Drive. Si vous optez pour cette solution, il faudra adapter le script en tenant compte qu'il n'y a qu'une caméra et que les enregistrements sont au format mp4.

Bonjour,

J'ai testé en redémarrant le Syno, de même en désinstallant et réinstallant Cloudsync, mais rien n'y fait.

J'ai vu sur le net que ce problème est déjà survenu chez pas mal de monde.

Pensez-vous que je pourrais essayer de reconstruire un script (en utilisant le votre) pour synchroniser mes fichiers avec Google Drive, sans passer par Cloud Sync -qui est manifestement buggé?

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Je propose dans un premier temps d'effectuer le changement suivant : créer un sous-répertoire dans le dossier partagé "surveillancebis" avec comme nom "clone".
Modifier la commande rsync pour pointer sur le sous-répertoire "clone" et s'assurer que le propriétaire de "clone" est "admin" et le groupe "users".
Le répertoire de synchronisation utilisé par CloudSync est "surveillancebis" dans lequel il y a "clone". Voici la commande qui pointe sur "clone" comme destination.

rsync -azur --delete-after --log-file="rsync.log"  /volume1/surveillance/ /volume1/surveillancebis/clone

Pour être certain que les modifications seront prises en compte par CloudSync, redémarrer le Syno.
Entrer en session "admin" et vérifier que CloudSync est actif (voir l'icône verte).
Via Putty.exe, exécuter le script pour que rsync synchronise le répertoire "surveillance" avec "surveillancebis/clone". (ne pas effectuer d'enregistrement vidéo dans "surveillance"  à ce moment)
Observer le comportement de CloudSync.
Quelques commandes concernant CloudSync qui pourraient servir :

#!/bin/sh

# récupère la valeur du PID de Cloud Sync dans le fichier syno-cloud-syncd.pid
if [ -f /var/run/syno-cloud-syncd.pid ] ; then
	PID_cloud_sync=`head -1 /var/run/syno-cloud-syncd.pid`
fi
echo "le pid de CloudSync = $PID_cloud_sync"

exit

En ligne de commande dans Putty.exe, exécuter la commande ps pour visionner les processus actifs. Repérer le processus de CloudSync (avec le pid).
Ce processus est :

/var/packages/CloudSync/target/sbin/syno-cloud-syncd /volume1/@cloudsync/config/daemon.conf  <<<< commande pour relancer le processus CloudSync

On pourra utiliser cette commande pour relancer le processus de CloudSync si on "tue" celui-ci avec kill (sans devoir redémarrer le Syno)

Pour tuer le processus : kill "-9" "$PID_cloud_sync"  -> relancer avec  /var/packages/CloudSync/target/sbin/syno-cloud-syncd /volume1/@cloudsync/config/daemon.conf
Pour geler le processus : kill "-19" "$PID_cloud_sync" -> dégeler avec kill "-18" "$PID_cloud_sync"

 

Modifié par aladec
Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Je propose dans un premier temps d'effectuer le changement suivant : créer un sous-répertoire dans le dossier partagé "surveillancebis" avec comme nom "clone".
Modifier la commande rsync pour pointer sur le sous-répertoire "clone" et s'assurer que le propriétaire de "clone" est "admin" et le groupe "users".
Le répertoire de synchronisation utilisé par CloudSync est "surveillancebis" dans lequel il y a "clone". Voici la commande qui pointe sur "clone" comme destination.

rsync -azur --delete-after --log-file="rsync.log"  /volume1/surveillance/ /volume1/surveillancebis/clone

Pour être certain que les modifications seront prises en compte par CloudSync, redémarrer le Syno.
Entrer en session "admin" et vérifier que CloudSync est actif (voir l'icône verte).
Via Putty.exe, exécuter le script pour que rsync synchronise le répertoire "surveillance" avec "surveillancebis/clone". (ne pas effectuer d'enregistrement vidéo dans "surveillance"  à ce moment)
Observer le comportement de CloudSync.
Quelques commandes concernant CloudSync qui pourraient servir :

#!/bin/sh

# récupère la valeur du PID de Cloud Sync dans le fichier syno-cloud-syncd.pid
if [ -f /var/run/syno-cloud-syncd.pid ] ; then
	PID_cloud_sync=`head -1 /var/run/syno-cloud-syncd.pid`
fi
echo "le pid de CloudSync = $PID_cloud_sync"

exit

En ligne de commande dans Putty.exe, exécuter la commande ps pour visionner les processus actifs. Repérer le processus de CloudSync (avec le pid).
Ce processus est :

/var/packages/CloudSync/target/sbin/syno-cloud-syncd /volume1/@cloudsync/config/daemon.conf  <<<< commande pour relancer le processus CloudSync

On pourra utiliser cette commande pour relancer le processus de CloudSync si on "tue" celui-ci avec kill (sans devoir redémarrer le Syno)

Pour tuer le processus : kill "-9" "$PID_cloud_sync"  -> relancer avec  /var/packages/CloudSync/target/sbin/syno-cloud-syncd /volume1/@cloudsync/config/daemon.conf
Pour geler le processus : kill "-19" "$PID_cloud_sync" -> dégeler avec kill "-18" "$PID_cloud_sync"

 

Bonsoir Aladec,

J'ai effectué les tests ci-dessus.

Le répertoire clone est créé. La modification du script fonctionne. J'ai bien récupéré le PID de cloudsync. Le processus correspond bien.

La commande kill -9 fonctionne; celle qui permet de relancer aussi.

En revanche, celle permettant de geler le processus ne marche pas: "can't kill pid 12897: No such process"  EDIT: cela fonctionne à condition de relancer la commande pour récupérer la valeur du PID.

Pour information, je teste en ce moment Hubic (25 Go) afin de vérifier si la synchro fonctionne mieux que sur Google Drive.

 

 

Modifié par frogdivision
Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Pour le kill "-19" "12897", il faudrait vérifier avant de tester cette commande si le processus 12897 est bien présent dans la liste des processus (commande ps en ligne de commande dans la console Putty pour obtenir la liste). Il est évident que si le processus de Cloud Sync n'est pas présent, il sera impossible de le "geler".

Comment se comporte CloudSync avec ces modifications ? La synchro avec Google Drive est-elle correcte ?
J'ai testé sur mon Syno (sans enregistrer de vidéos avec Surveillance Station) et cela fonctionnait correctement.
Il faudra passer à l'étape suivante si cela va bien (faire fonctionner rsync lors d'un enregistrement vidéo)

 

Modifié par aladec
Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Content que cela fonctionne avec Hubic.
Pour enlever le doute, pourriez-vous tester de la même façon avec Google Drive et donner le résultat du test ? Merci d'avance.

Bonsoir,

Pour le moment, cela fonctionne aussi avec Google Drive, même si les vidéos n'apparaissent pas 'naturellement' dans le répertoire distant et qu'il faut aller cliquer sur le nouveau fichier vidéo dans les fichiers récents pour le voir s'afficher ensuite.

Cordialement,

Lien vers le commentaire
Partager sur d’autres sites

Je me vois pas perso mettre la vidéo sur du cloud public... D'ailleurs quid de delais réel étre la détection et l'upload finale... Qui plus est d'une archive... Autant une vidéo tronquée à l'upload est visible facilement... Une archive c'est plus délicat... Que faites vous si les mecs en arrivant coupe le courant et/ou la ligne telephonique ? (Ce qui est généralement le cas pour la neutralisation des alarmes)

Je vois que deux solutions... Déjà dans les deux cas la sécurisation du cable téléphonique extérieur ou alors un modem prenant en charge une clé 3G... Alimentation de secours pour les caméras. Concernant le synology... Le mettre avec le modem et un onduleur, dans un caisson en titane étanche ou alors l'emmurer.

méthode radicale, mais efficace ;-)

Lien vers le commentaire
Partager sur d’autres sites

 

Mettre la vidéo sur un cloud public n'est pas un problème en ce qui me concerne: il s'agit d'avoir une sauvegarde hors de chez moi en cas de cambriolage. Les vidéos ne sont pas des fichiers sensibles et le cloud n'est pas non plus ouvert aux 4 vents. Pour les plus paranos, il existe aussi la possibilité de crypter les fichiers (à condition de mettre en lieu sûr la clé de décryptage). L'upload s'effectue dans la minute qui suit l'apparition de la vidéo dans le dossier surveillance.

C'est vrai que certains cambrioleurs coupent l'électricité, mais dans une majorité des cas, le vol est une affaire d'opportunité (porte ouverte, départ en vacances visible, etc ...) et le vol n'est pas toujours réalisé par un spécialiste. Le zonard de base n'a pas forcément tout prévu ...

Concernant le back-up en 3G, cela peut fonctionner également à moins que le cambrioleur soit un habitué et dispose d'un brouilleur. Cet appareil brouille les fréquences mobiles mais aussi des alarmes sans fil (c'est la raison pour laquelle les modules des alarmes sans fil vérifient toutes les minutes leur bonne connexion entre eux).

Uploader chaque jour de nombreuses vidéos qui peuvent faire plusieurs dizaines de Mo chacune sur un site distant va rapidement grignoter le forfait mobile en question...

Le vrai pro du cambriolage rentrera n'importe où et fera effectivement le nécessaire pour couper le jus... Mais avant ça, il laissera peut-être une empreinte vidéo de son repérage.

Mettre le Synology au coffre ... Why not. La chaleur va rapidement mettre le système en difficulté. Ne  disposant pas de ce type d'équipement, je préfère le mettre dans un endroit peu visible. Si le voleur est pressé ...

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Le fait d'utiliser des caméras de cette manière en prenant le risque que le cambrioleur coupe l'alimentation électrique n'est pas une solution à écarter.
J'ai été victime de 5 cambriolages sur 30 ans et les cambrioleurs n'ont jamais coupé l'alimentation électrique. (ce ne sont pas des "pros"). De plus le système d'alarme est pourvu d'une alimentation de secours sur batterie avec appel téléphonique en cas d'intrusion. Lors du dernier cambriolage, j'ai été averti par l'appel téléphonique automatique et je me suis connecté à la seule caméra que je possédais à l'époque (il y à maintenant 1an1/2). J'ai constaté qu'une porte était ouverte et donc qu'il ne s'agissait pas d'une alarme intempestive. 
Les caméras apportent donc un plus. Elles sont maintenant au nombre de 3 avec un enregistrement vidéo des zones de surveillance. Elles constituent aussi un outil de dissuasion.
On pourra toujours discuter sur la qualité de protection en tenant compte du rapport qualité/prix du système utilisé. A chacun de choisir et de s'adapter en fonction de son expérience.

Revenons au véritable sujet de ce post et limitons aux solutions proposées.

Lien vers le commentaire
Partager sur d’autres sites

  • 4 semaines après...
  • 3 semaines après...
  • 1 mois après...

Bonjour,

Actuellement le script qui active les caméras et réalise des archives zip synchronisées avec Google Drive me donne entière satisfaction.
Il est dommage que pour que ce script s'exécute toutes les 5 minutes, il soit nécessaire d'allumer un ordinateur et de se connecter au Syno afin de déclencher la tâche "cron" via le "planificateur de tâches". Il faut ensuite brancher le signal d'alarme qui est indépendant du système. Pour stopper, il faut effectuer les opérations en sens inverse. J'ai remarqué que pour de courtes absences, la procédure de mise en activité des caméras n'était pas exécutée car il faut trop de temps pour la mise en œuvre. De plus lorsque la maison est occupée, le signal d'alarme est branché durant la nuit mais en général les caméras ne sont pas activées.

Pour remédier à ces problèmes, il faut donc interagir entre la centrale d'alarme et le Syno.


- lorsque le signal d'alarme est branché, les caméras sont activées automatiquement via le Syno.

Il faut donc trouver le chaînon manquant entre la centrale d'alarme et le Syno.
Je propose de tester avec un micro-ordinateur "Arduino Yun"
Un relai se ferme lorsque le signal d'alarme est branché (relai 12v alimenté par la centrale d'alarme).
L'Arduino reçoit l'information de la part du circuit de relai comme un interrupteur ouvert ou fermé.
L'Arduino devra transmettre au Syno via le réseau ethernet l'information reçue.
Relai fermé = démarrage des caméras et toutes les 5 minutes, vérifier s'il y a des enregistrements.
Relai ouvert = ne fait rien ou arrête les caméras et la vérification des enregistrements.
Relai ouvert/fermé rapidement = déclenchement du signal d'alarme

Cela nécessite sur le Syno de faire tourner un serveur à l'écoute de l'Arduino Yun - Ok avec netcat en bash
C'est l'Arduino qui donne l'ordre au Syno de démarrer ou d'arrêter les caméras en fonction de l'état du relai.
Toutes les 3 minutes, lorsque les caméras fonctionnent, une vérification d'enregistrement est demandée au Syno (synchro avec Google drive)
Lorsqu'il y a un déclenchement d'alarme, l'arduino demande au Syno de réaliser des appels téléphoniques automatiques avec message enregistrés au format wav.

[EDIT du 17/02/2016] concernant le script de la page 1 de ce post dans lequel la commande "awk" est utilisée.
Suite à une maj du Syno, la commande "awk" (fichier awk) se trouve maintenant dans /usr/bin donc dans le script il faut changer "awk" par "/usr/bin/awk" . Sans ce changement, le script fonctionne toujours mais les statuts de "CloudSync" ne sont plus valables.

[EDIT du 05/04/2016] Attention suite au passage à la DSM 6, les scripts précédents ne fonctionnent plus entièrement.
Une adaptation sera nécessaire. Du travail en perspective ...

 

 

 


 

 


 

 

 

Modifié par aladec
Lien vers le commentaire
Partager sur d’autres sites

  • 3 ans après...

Bonjour,

Je me permet d'intervenir sur le sujet car étonnamment, chez moi je n'ai pas besoin de créer d'archive ou de dossier miroir.

Cloud Sync synchronise directement les dossiers de Surveillance Station avec le cloud ( Google drive )

Sauf que sur Google Drive, il n'est pas possible de vider automatiquement la corbeille ! Ce qui devient gênant lorsque celle ci est pleine.

J'ai 3 caméras auxquelles j'ai donné 5 Go pour la rotation des données, fois 3 cela donne 15 Go , et lors de la rotation des données, Cloud Sync supprime les données sur Drive mais ces dernières vont à la corbeille et au bout d'un certain temps la synchro ne fonctionne plus car l'espace cloud est plein.

De plus cela limite l'utilisation de Surveillance Station puisque je n'ai que 5 Go d'archive alors que mes disques font 2 To. 

Sans parler des ressources et de la bande passante utilisée !

Je suis donc à la recherche d'une autre solution, l'idéal serait d'activer cette synchro uniquement en mode absence , peut être une commande envoyée par Jeedom ?

Seulement , il faut également trouver un moyen de synchroniser uniquement les fichiers inférieurs à 1 jour, voir 1 semaine. Ce que Cloud Synch ne propose pas.

J'ai essayé Rclone et Cloud Sync Pro sur Jeedom mais pour l'instant rien de concluant.

Lien vers le commentaire
Partager sur d’autres sites

  • 1 an après...

Bonjour,

Je découvre avec surprise une publication en mai 2019 concernant ce sujet.
Nous sommes maintenant en janvier 2021 et le système fonctionne toujours suite à différentes adaptations.
Il y a 3 caméras (1 licence supplémentaire) qui fonctionnent avec Surveillance Station.
2 caméras supplémentaires avec ZoneMinder sur Raspberry Pi3.
1 interface entre le système d'alarme et le Nas Synology réalisée avec un Arduino Uno qui déclenche un script sur le Nas lorsque le signal d'alarme est branché.
La Synchro avec Google Drive n'est plus activée pour des raisons budgétaires.
Lors du dernier cambriolage, nous avons pu fournir des vidéos  de nos 2 voleurs qui ne sont pas restés très longtemps.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.