|
Angelo,
You might look at "Back in time"
https://backintime.readthedocs.io/en/latest/mainwindow.html This
is a Python script that uses rsync as the backup mechanism but
has GUI front end to allow configuration. The only caveat is that
it does not seem to work with NTFS file systems. I formatted my
backup drive (USB Plug in external) as ext4 and it works very
well.
~~R
On 7/5/19 7:45 AM, Angelo Moreschini
wrote:
Hi,
although I did a lot of tests with many engagement I was
not able to catch the UDEV event ....
Having exhausted my trust ... I give up.
I will not try bacula which (perhaps) is excessive for my
purposes, and so I'll try with a simple script that uses the
rsynk utility to copy the only files that I are in my
interest.
I have already successfully used this method, but that time I
mounted permanently the HD USB to the computer via the file
fstable ( this caused problems) but this time I will do
otherwise :
I'll simply mount and unmount the HD USB via the script .
The only drawback (and it is not a serious inconvenience) will
be the need to connect and disconnect the HD USB before that
l'll launch the script during the time it is running.
Thank you to all that tried to help me
Angelo
You should be using the UUID of the partition
to detect and mount your target. Detecting the "whole"
drive is immaterial, since you want udev to mount a
partition, not a drive.
I would try to get one partition working first, then
proceed to the others. With udev testing, I've always had
far more luck testing individual tasks, one by one. Throw
too much stuff at it, and you can't tell what's not
working: udev, your script, or you.
HI Seth,
I'm sorry to
still bother you
..., but your help could save me a lot of
useless tests (since there
are many parameters to manage and knowing what I
really have to do
could, this trigger me the use of useless ones).
I
think that I understood the crux of the problem
... (the UDEV theory
…) but I still have a doubt that comes from the
division of my HD
into partitions (to how this particularity can
influence my particular problem).
I
would like exactly to know if UDEV reveals the
existence of the
entire HD USB, or if instead it detects only
the individual existence of
the three partitions that are mounted there ..
|
Because
I read this.., I think that I could be
able to check the real “work” of UDEV
on my computer :
“Whenever
you connect to the system, the kernel
detects and initializes it, and
directory with the device name is
created under / sys / directory which
stores the device attributes.”.
This
could be a great help, but I couldn’t
identify “this: sub-directory…., in the
/sys directory, they are there many
directories with many ramifications
, how I can to identify the one in
which they are stored the attributes of
the device whose presence is detected by
UDEV?
|
Knowing
if UDEV only reveals the existence
of the (three) partitions and not the existence
of the entire HD also
has reflections on the script script that uses
rsynk to carry out the
bak-up.
This
is because (probably) I should write three
scripts that
use the utility rsync (one
script
for
each partition) and not a single script
that acts on the three different partitions.
Thank you
regards
Angelo
On Wed, Jul 03,
2019 at 07:16:17AM +1200, Seth Kenlon wrote:
> Using the UUID is correct.
>
> If the script isn't being executed by udev but
you can confirm that
> udev is correctl mounting your target
partition, and the shell script
> functions as expected when you run it manually,
then I would create a
> simple timestamp shell script just to confirm
that you can get a shell
> script to do *something* due to a udev event.
The more complex the
> shell script, the more variables you have to
debug, so simplify your
> shell script and work to just get a time stamp
(or something) when a
> udev event occurs.
I've done that by embedding echo commands into the
script that
will put debugging statements a debug file that you
can look
at after bootup.
put one statement before anything else in the script
and if you
don't get any debugoutput you'll know the script
isn't being run.
Fred
>
> On Tue, Jul 2, 2019 at 3:07 AM Angelo
Moreschini
> <mrangelo.fedora@xxxxxxxxx>
wrote:
> >
> > thank you Seth,
> >
> > I have no problems with the script
executed at the UDEV event (if this is the meaning
you attribute to the term <UDEV script>).
> > I've already done this script that works,
if run from a terminal.
> > If by the term <UDEV script> you
mean something different, please tell me.
> >
> >
> > The problem is that this script is not
executed as a result of the UDEV event.
> > - - - - - -
> > But maybe there is still something not
clear for me that I can ask you:
> > The HD (USB) that I am using, is divided
into three partitions (in order to keep the saved
data separate):
> > = - = - = - = - = - =
> > the blkid command give this output ...:
> > / dev / sdc1: LABEL = "PRTZm_sys-admin"
UUID = "1A5CEE7149E4BA81" TYPE = "ntfs" PARTUUID =
"0007fd62-01"
> > / dev / sdc2: LABEL = "PRTZm_data-common"
UUID = "7FB1E3D91206DE1C" TYPE = "ntfs" PARTUUID =
"0007fd62-02"
> > / dev / sdc3: LABEL = "PRTZm_programming"
UUID = "0A69FDE9688969D9" TYPE = "ntfs" PARTUUID =
"0007fd62-03"
> > = - = - = - = - = - =
> > so far, till now, I tried to reveal the
montage of the HD without taking into the account of
partitions into which the USB HD is divided ..
> > But since the blkid command does not
reveal its own UUID I am now thinking that this
could be the problem.
> >
> > IN CONCLUSION, since the USB is divided
into partitions, ... will the UDEV event reveal the
presence of the entire HD (as the sole unit), or
will it instead reveal the presence of the three
individual different partitions?
> >
> > Still I would ask .... : this is a good
syntax ? ENV{ID_FS_UUID}=="1A5CEE7149E4BA81"
> > and still also, :-) ....
> > what I have to use the UUID number, or
instead the PARTUUID number ?
> >
> > thank you very much
> > Angelo
> >
> > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon
<skenlon@xxxxxxxxxx>
wrote:
> >>
> >> Angelo,
> >> I agree with Tom's analysis, but my
udev script accounts for it by
> >> mounting your drive with a very
specific designator.
> >>
> >> Here is how I have tested this sort of
thing before:
> >>
> >> 0. Get the UUID of your drive with
blkid
> >> 1. Write a udev script to detect your
drive by UUID when attached, and
> >> to execute a test shell script (such
as /usr/local/bin/angelo-test.sh)
> >> when the drive is attached
> >> 2. Create the script
/usr/local/bin/angelo-test.sh to do something
> >> very simle, like echo `date` >>
/tmp/backup.log, and make it
> >> executable
> >> 3. Reboot
> >> 4. Attach your drive, and then look
for the execution of your test
> >> script. If there was a /tmp/backup.log
created with the correct date
> >> and time in it.
> >> 5. Look in /media to ensure that your
drive has been mounted as a
> >> unique and persistent entitiy.
> >>
> >> If it worked, then change the script
to your real backup script.
> >> Continue to test.
> >>
> >> If it failed, review your udev script,
use `udevadm monitor` to
> >> discover why your drive isn't
triggering your script.
> >>
_______________________________________________
> >> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> >> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxxxxxxxxxxx
> >
> >
_______________________________________________
> > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
--
---- Fred Smith -- fredex@xxxxxxxxxxxxxxxxxxxxxx
-----------------------------
"For him who is able to keep you from falling and
to present you before his
glorious presence without fault and with great
joy--to the only God our Savior
be glory, majesty, power and authority, through
Jesus Christ our Lord, before
all ages, now and forevermore!
Amen."
----------------------------- Jude 1:24,25 (niv)
-----------------------------
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
|
