Hi Seth,
after reading the answer from Tom, (the duration of the tread) I am no longer sure that a scrpt acting at the event to connect an HD USB to the computer to back up the data may be the best solution for me .

I'm dealing with the problem of backing up data on my computer for a long time.
I had it solved years ago by launching a script (both from the terminal and through the graphical menu) that used the linux <rsync> command.

I used this method for months (maybe more than one year), but over time the back-up directories on the USB HD were considered and used by Fedora as an integral <stable> part of the computer causing problems .. one of which (the most annoying) was the request to access the USB HD.
I remember that this always happened when I used the <find> command and at the end I also had a data leak (a back-up HD partition got corrupted and became inaccessible).

I tried to use the UDEV rules to exclude the automatic mounting of the USB HD, but without access. ....Reading the TecMint article made me think I had a possible solution ...

I also took interest in using bacula ... and I lost some time figuring out how this tool (bacula) works .., but in the end I gave up, because I got the idea that bacula has a different goal (much bigger) of what I propose: my objective is to save my work (I am a programmer) once a day or at least a few times a week.

Having seen that you have experience in the field, I kindly ask you to give me your guidance regarding the solution of my back-up problem.

thank you
Angelo

On Mon, Jul 1, 2019 at 8:18 AM Angelo Moreschini <mrangelo.fedora@gmail.com> wrote:

Thank you Tom,

OK,I hadn't consider, at the moment,  the threat duration aspect,.
The script (to execute for the UDEV 'event) cannot be affected by this kind on problem because  it have only to  write a small file, his content is : <touch ~ / Documents / new-touch_filet >
This script carries out its task when performed from the command line . I'll change his content at right moment..

Hi Seth,
I understand what you say,  ... and thank you for yours advice.

As well I have not experience with this kind of problem I'll begin do do what you already suggested me... 
I'll post again a massage if I need help

thank you
 Angelo

On Sun, Jun 30, 2019 at 10:34 PM Seth Kenlon <skenlon@redhat.com> wrote:
That tecmint article has several serious issues with it (this is
reflected in the comments, too).

You need a slightly more complex script for what you are attempting.
This is based on Attachup, a pyudev srcipt that backs-up a thumbdrive
to a computer upon attaching it - but you can make your shell script
do whatever you like.  https://gitlab.com/slackermedia/attachup

```
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
IMPORT{program}="/sbin/blkid -o udev -p %N"
# Get label or create one
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
# mount
ACTION=="add", ENV{mount_options}="relatime"
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
# mount and start backup script##
## replace UUID_OF_PARTITION with the UUID of your destination partition
ACTION=="add", ENV{ID_FS_UUID}=="UUID_OF_PARTITION", RUN+="/bin/mkdir
-p /media/%E{dir_name}", RUN+="/sbin/mount -o $env{mount_options}
/dev/%k /media/%E{dir_name}", MODE="0770", GROUP="users",
RUN+="/usr/bin/mrs-auto_backup.sh"
# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/sbin/umount -l
/media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"
# Exit
LABEL="media_by_label_auto_mount_end"
```

Replace UUID_OF_PARTITION with the UUID of the partition that you want
to backup to. You can obtain the UUID with the ``blkid`` command (make
sure the drive is attached at the time).

Make sure you are in the ``users`` group (or else use a group that you ARE in).

Install that code as a udev rule, and then reboot (I still don't trust
udevadm control --reload).

When you attach your drive, it will get mounted to /media.

Change your backup script (/usr/bin/mrs-auto_backup.sh) so that it
back-ups to what gets mounted in /media. I find that this helps ensure
a reliable and unique location for your backup destination.

Make sure your backup script (/usr/bin/mrs-auto_backup.sh) is executable.

Good luck!

On Mon, Jul 1, 2019 at 12:40 AM Angelo Moreschini
<mrangelo.fedora@gmail.com> wrote:
>
> Hi,
> in order to backing up data when I connect to computer an USB HD, I wrote the follow UDEV rule :
> ------------------------------------------------------------------
> SUBSYSTEM=="block", ACTION=="add", ATTRS{vendor}=="152d", ATTRS{model}=="0578",  SYMLINK+="external%n", RUN+="/usr/bin/mrs-auto_backup.sh"
> -------------------------------------------------------------------
> the rule is the content of the file : /etc/udev/rules.d/10.autobackup.rules
> that I self created .
>
> I learned this method at the link : https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/  ("How to backup files to USB media when connected")
>
> As well I tried in many different combinations and parameters values, never I was able to execute the script inside the rule.
>
> -----
> In order to get the USB HD characteristic of the USB Hard Disk to use for backing-up the data I used the command :
> <sudo udevadm info -q all -n /dev/sdc>
> and its output is transcribed below
>
> Could someone help me to understand because this rule doesn't works ?
>
> thank you
> regards
> Angelo
> -------------------
> features (attributes) of the USB Hrd Disk that I got with the above command    :
> [angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc
>
> P: /devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> N: sdc
> L: 0
> S: external
> S: disk/by-path/pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> S: disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
> E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> E: DEVNAME=/dev/sdc
> E: DEVTYPE=disk
> E: MAJOR=8
> E: MINOR=32
> E: SUBSYSTEM=block
> E: USEC_INITIALIZED=11404758453
> E: ID_VENDOR=JMicron
> E: ID_VENDOR_ENC=JMicron\x20
> E: ID_VENDOR_ID=152d
> E: ID_MODEL=Tech
> E: ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
> E: ID_MODEL_ID=0578
> E: ID_REVISION=0203
> E: ID_SERIAL=JMicron_Tech_DB12345681BC-0:0
> E: ID_SERIAL_SHORT=DB12345681BC
> E: ID_TYPE=disk
> E: ID_INSTANCE=0:0
> E: ID_BUS=usb
> E: ID_USB_INTERFACES=:080650:080662:
> E: ID_USB_INTERFACE_NUM=00
> E: ID_USB_DRIVER=uas
> E: ID_PATH=pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0
> E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_5_1_2_1_0-scsi-0_0_0_0
> E: ID_PART_TABLE_UUID=0007fd62
> E: ID_PART_TABLE_TYPE=dos
> E: DEVLINKS=/dev/external /dev/disk/by-path/pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0
> E: TAGS=:systemd:
>
>
> _______________________________________________
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org