Best Practice Preparing For Disk Restoring System

Home » CentOS » Best Practice Preparing For Disk Restoring System
CentOS 9 Comments

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!

9 thoughts on - Best Practice Preparing For Disk Restoring System

  • 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.

  • 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!

  • According to rear webpage: https://relax-and-recover.org/about/

    Extensive disk layout implementation, incl.

    * HWRAID (HP SmartArray)
    * SWRAID
    * LVM
    * multipathing
    * DRBD
    * iSCSI
    * LUKS (encrypted partitions and filesystems)

    I personally used rear to restore lvm volume groups and several logical volumes with success.

    I will test a more complicated layout until the end of this year and can let you know about the findings.

    Regards,

    Felix

  • Thanks for that. I only picked up on rear this morning, I suppose if you don’t go looking for it you’ll never find it. A combination of the paper Site Management Guide and the nightly disk summary have worked for over 20 years on *NIX! VMS before that was totally different, but we still kept paper copies of configuration.

    —
    J Martin Rushton MBCS

  • There is enterprise class open source backup software worth mentioning: bareos (and bacula which it forked from). I use them for over a decade, bacula first, then I switched over to bareos. I back up using bareos UNIXes (FreeBSD), Linuxes (CentOS), MS Windows.

    Valeri