On Wed, 13 Nov 2019 13:53:38 +1100, faeychild wrote:
Subject: att BitTwister
I thought I mentioned you did not need att BitTwister in subject line.
I can suggest you always use a subject line to get subject matter
experts attention.
Some people my take your current subject as wanting a personal thread
without anyone else partition.
I took the liberty of changing it to a more appropriate which will
make it easier for anyone looking to do the same thing to find the
thread in the future.
Hi Bits
Evening faeychild
the time is coming to backup "/"
I should hope so. :)
I know for sure that typing the command into the sysrescue terminal is
going to cause fat finger and blind eye syndrome
A script is a better way to go.
I would agree/suggest so. With a little effort, it can be made to
also keep you out of trouble.
So I thought I'd ask your approach.
How do you access the script.
Boot other install run level 3
login as root
bkup_mga7
or
restore_mga7
for whichever way wanting to do what to mga7
If booted runlevel 5 (gui)
click up a terminal
su - root
bkup_mga7
Did you install in the sysrescue ISO?
No. I always install on my system using Mageia iso.
Did you install on the "src" filesystem
Or a method I haven't thought off?
Or I have no good idea what "install" means.
Starting to guess, you are asking about the script install and how to
launch it.
Placing script on a rescue cd, means you have to repeat the script install anytime you modify the script or a new release of the rescue media is installed.
That is way too much maintenance for me.
Having said that, method/launch depends on system setup.
I have a separate partition for my system wide stuff,
$ ls /local
bin cron icons log opt ppp tmp
config doc lock lost+found phone sounds
/local/bin has my system wide scripts, icons for desktop icons to keep
the same look regardless of install/desktop, sounds for playing wav files
for error, success, mail,.....
What that allows me to do when required to use a rescue media is
mkdir /local
mount -t auto LABEL=local /local
/local/bin/restore_mga7 or
/local/bin/bkup_mga7
******************
************ Trial script
*********** backup only
#! /bin/bash
#
#
#
_mga_7=/dev/nvme0n1p2/
_mga_bu=/dev/nvme0n1p5/
Hard coding device partition id is not my preferred method, can be error
prone, devastating if you add/delete/re-partition/move install, ......
Seems like I spent a week or more trying to get you to use label/name
for your partitions. Tell me if the following is less error prone or not.
_src=mageia
_dest=mageia_bu
That makes it bit more obvious as to which is what. As coded, indicates
you will need another script to do a restore. You may be surprised to
find out how easy it will be to use command line arguments to pick doing
a backup or restore, or different partitions with the same script.
Come Mageia release 8, may cause more problems.
Yes, I know it is just a beginning point, I just want you keep it in mind.
mkdir /src
mkdir /dest
Using the above label names in the variables, the mount command becomes
mount -t auto LABEL=$_src /src
mount -t auto LABEL=$_dest /dest
rsync -aAHSXxv /src/
--exclude={"/dev/*,"/proc/*","/sys/*","tmp/*","/run/*","/mnt/*","/video/*","/me dia/*","/lost+found"}
/dest
## end******************************
I can recommend just
rsync -aAHSXxv /src/ /dest
at this point, when not attempting to back up an unmounted / partition.
All those /whatever excludes are needed if attempting to backup
a running / and if you were to check each argument as to what it does,
you might find one or more which tells rsync to not go outside of the
partition for files.
In other words you did not have to exclude /video and none of the other partitions are not actually there unless you are actually running in /.
lost+found is the exception. Normally all partitions get
a lost+found. I do not bother excluding it, because there is nothing
in it unless something clobbered inode chain. which cause best guess
of the file to be placed in lost+found.
If doing a restore, I suggest you would want it to be restored. :)
I have a cron job always checking lost+fouund partitions on my system
to warn be about the problem.
As coded to date, it is doing the desired commands put without any
checking of return status. You can test for successful operation by
checking $? for non-zero value. That applies to the great majority of
apps. However I have see one or two, which do not. Always best to check
man page of app to see if exceptions exists.
Quick down and dirty example:
rsync -aAHSXxv /src/ /dest
if [ $? -ne 0 ] ; then
echo " Fatal error 1 running rsync -aAHSXxv /src/ /dest"
exit 1
fi
Homework, man test
For anyone coding, You might think about the 6 P's
Prior Planning Prevents Piss Poor Performance.
When starting out to code a script, I can recommend writing down all the requirements required of the script. That way you can use the majority
of those as comments to make it easy to find the operation, and to know
you have completed coding all of the requirements.
Yes, I know this is just a beginning script, but you will get a better
product quicker in the long run. If you are not going to document
all the requirements and just start hacking out code, you need to stop
at each line of code and think about Murphy helping you into the ditch.
I suggest idiot proofing the code and lots to tests to help you to locate problems much faster than having to research code operation to find out
about a problem during real world operation.
Some examples:
Can only run as root
can not run if running / is to be restore/backed up.
src/dest do not exists
src/dest can not be the same
By the way, I find that when I have to duplicate something it is better
to have it in one place to keep maintenance down if requiring change.
Take your rsync arguments as example in this code snippet. That way
rsync_args can be in one place for change, and have the additional
benefit of the code being able to change them without having to
dink around with duplicate rsync lines to do different type of backup.
script -c "rsync $_rsync_args /src/ /dest" $_rsync_log_fn
_rtn_status=$?
if [ $_rtn_status -ne 0 ] ; then
echo "Fatal $_exe error 15 running
rsync $_rsync_args /src/ /dest
return status: $_rtn_status
log: $_rsync_log_fn
"
exit $_rtn_status
fi
Homework man script
Another tip, I like using _app and _exe in my code. That allow me much
more flexibility than hard coding the names and improves
maintenance/coding time. Example:
_app=${0##*/}
_exe=$0
_temp_dir=/somewhere
_report_fn"$_temp_dir/$_app.rpt"
_rsync_log_fn="$_temp_dir/${_app}_rsync.log"
_temp_fn="$_temp_dir/$_app.tmp"
Take my backup/restore script (bkup_restore) for example.
One script, but executed using different names.
Maintenance wise, I just create another link for new releases, and delete
links of old releases. At the moment a ls -al /local/bin snippet
bkup_restore
bkup_mga4 -> bkup_restore
bkup_mga5 -> bkup_restore
bkup_mga6 -> bkup_restore
bkup_mga61 -> bkup_restore
bkup_mga7 -> bkup_restore
bkup_mga71 -> bkup_restore
restore_mga4 -> bkup_restore
restore_mga5 -> bkup_restore
restore_mga6 -> bkup_restore
restore_mga61 -> bkup_restore
restore_mga7 -> bkup_restore
restore_mga71 -> bkup_restore
restore_net_ins -> bkup_restore
bkup_restore parses $_app to get what to do bkup/restore
and source directory name.
Saves me having to call script with what to do with whom arguments.
set -- $(IFS='_' ; echo $_app)
$1 will have bkup or restore
$2 will have source partition label.
--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)