CentOS - Nov 2020 - Best practice preparing for disk restoring system

On 18/11/2020 03:35, H wrote:
> On November 17, 2020 4:07:52 PM EST, "Felix K?lzow"
<felix.koelzow at gmx.de> wrote:
>> Maybe "rear" is an appropriate solution for you?
>>
>> https://relax-and-recover.org/
>>
>> On 17/11/2020 18:23, Chris Schanzle via CentOS wrote:
>>> I would include LVM and mdadm info as well, since I use those
>> features.? I encourage you to look at what long-lived tools, such as
>> clonezilla, write into their archive directories.? It's impressive.
>>> If you zero out all free space on all of your HDD partitions (dd
>> bs=1M if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use
>> 'fstrim' for SSD's, you could use dd to image with fast
& light
>> compression (lzop or my current favorite, pzstd) and get maximum
>> benefit of a bit-by-bit archival copy.
>>>
>>> On 11/16/20 11:02 PM, H wrote:
>>>> Short of backing up entire disks using dd, I'd like to
collect all
>> required information to make sure I can restore partitions, disk
>> information, UUIDs and anything else required in the event of losing a
>> disk.
>>>> So far I am collecting information from:
>>>> - fdisk -l
>>>> - blkid
>>>> - lsblk
>>>> - grub2-efi.cfg
>>>> - grub
>>>> - fstab
>>>>
>>>> Hoping that this would supply me with /all/ information to
restore a
>> system - with the exception of installed operating system, apps and
>> data.
>>>> I would appreciate any and all thoughts on the above!
>>>> _______________________________________________
>>>> CentOS mailing list
>>>> CentOS at centos.org
>>>> https://lists.centos.org/mailman/listinfo/centos
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> https://lists.centos.org/mailman/listinfo/centos
> Thank you, that tool is new to me but looks very interesting!
> _______________________________________________
Yes, indeed. Up to now, I have very good experience with that. Setup new
server. Create "rear" backup on USB, nfs-share or more secure via

sshfs. Destroy Raid, Create new Raid. boot from rescure image. type
"rear recover". DONE. All that in less than 10 minutes.

I'm old school, but I always liked using dump/restore on unix file
systems.  e2dump or whatever for linux, zfs send/recieve for zfs, ufsdump
on freebsd ufs, etc etc.

then I just need to know what file systems they are, and where they should
be mounted, and its trivial to set tha tup on new hardware.

I'd agree with you John.  I'm trying to get away from Amanda's 
unpredictability and go back to using scripts to drive dump (for 
ext2/3/4) and xfsdump (for xfs).

Is there any easy way to tell rear to include xfsdump and dump 
capability?  If the commands are there then its trivial to restore data.

What I've done in the past is before the nightly backup write a small 
file to the root of each filesystem giving disk geometries.  You can 
then use any recovery DVD to partition and reload the OS.  If rear can 
do this for me it would be __much__ neater!

On 18/11/2020 08:24, John Pierce wrote:
> I'm old school, but I always liked using dump/restore on unix file
> systems.  e2dump or whatever for linux, zfs send/recieve for zfs, ufsdump
> on freebsd ufs, etc etc.
> 
> then I just need to know what file systems they are, and where they should
> be mounted, and its trivial to set tha tup on new hardware.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
> 
-- 
J Martin Rushton MBCS