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!
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@centos.org https://lists.centos.org/mailman/listinfo/centos
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@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On November 17, 2020 4:07:52 PM EST, "Felix Kölzow" felix.koelzow@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@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thank you, that tool is new to me but looks very interesting!
On 18/11/2020 03:35, H wrote:
On November 17, 2020 4:07:52 PM EST, "Felix Kölzow" felix.koelzow@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@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@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@centos.org https://lists.centos.org/mailman/listinfo/centos
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.
On 18/11/2020 12:47, Felix Kölzow wrote:
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
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Nov 18, 2020, at 3:27 AM, J Martin Rushton via CentOS centos@centos.org wrote:
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).
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
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@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Chris Schanzle -
Felix Kölzow -
H -
J Martin Rushton -
John Pierce -
Valeri Galtsev