Hi:
I’m trying to restore to a new SSD/disk from a full folder/file backup and change the partition sizes from my current setup. after a week of trying various approaches I decided that I should ask about this before wasting another week. I need to restore all my desktop customizations , changes to the grub (turn of the splash screen), added nvidia driver, installed probably 20-30 applications.
The general way that I have been doing this is install from the original live cd with new partition sizes and then restore/overlay from the borgbackup all the files and directories that I think are needed.
I tried backup of root (/) including the /boot but this would not boot. I expect that the grub config need to be changed for new partition uuid’s and reinstalled. There may be something else that needs to be done but I’m at a loss to known what it is.
I tried just a full backup the root(/) and that booted up to the login screen but still had the splash screen on bootup. I was able to login but it hung after displaying the Wallpaper correctly. I did an alt-f2 to get a tty and look at the journalctl log. Apparently, systemd was in a loop trying to load nouveau driver. This is unexpected since I expected the nvidia driver to be restored from the backup. This means to me that the nvidia driver files must be on the /boot partition. I did preserve the fstab from the live cd installation as the uuids had changed from what was on the backup.
I have been running all these trials for backup and restore from the original live cd. I exclude the following directories from the backup: /proc, /dev, /sys, /run, /.snapshots, /srv, /tmp, /var/run .
I did some searching of files on the system and found uuid’s mentioned the CUPS directories. Since the printer has not changed I would not expect the uuid to change
Has anybody done a full file and directory restore onto a new disk preserving all the changes made on the system that the backup was made from? Do you have any things for me to try?
For / filesystems I either install fresh, which can be simpler, or use imaging, so there are either three “disks” involved: 1 for running the process, 2 for the source, 3 for the new; or more often, because of I’m multibooting, all is done partition at a time booted to an installation not involved in any current alteration process. When I want a larger filesystem on the target, I create one the desired size, restore the image, then do a resize2fs. I only use EXT partition types. Of course, source and target cannot be involved in a boot process together in one PC at the same time until all UUID and LABEL duplication is eliminated. My fstabs are configured to use primarily human memorable labels rather than UUIDs somewhat simplifying the ordeal, and still there’s Grub to both reconfigure to account for the altered UUIDs and LABELS, as well as install to the appropriate sectors. It’s definitely not a simple process here.
I’m sorry that I was not more explicit. I’m using the standard Opensuse defaults : root=BTRFS, home=XFS, efi=FAT. Thank you for your reply anyway.
It seems to me that there should be tools to do this since other people could experience a fatal disk hardware error and want to move the whole installation to a new disk. I have not found any documentation on Opensuse or Suse site that has a procedure that works, I would appreciate any pointers to documentation that has the information requested.
“This” is a rather simple process when you don’t specify “change the partition sizes from my current setup”, which complicates significantly. Any number of tools can make a working true clone from a working disk, e.g. dd and Clonezilla.
Borgbackup and/or its community should include documentation on how to restore, and what limitations it may have, if any, WRT changing partition sizes. I’ve never used it.
Not what I asked for. I did not ask for bit by bit clone, because I am not restoring to partitions of the same size. I need to shrink the XFS partition ,expand the BTRFS partition, and leave some unpartitioned space on the drive. I need the restore from complete backup of all files on the original disk accounting for the changes in UUID and any other changes required to incorporate all the changes made on source disk since it was installed from the liveCD.
From the responses, I conclude either they did not read the request carefully or didn’t understand it or have no idea how to do it. Consequently, I guess that I will have to spend more time experimenting with the restore procedure.
When you are worrying that disk/partition UUIDs that have changed are in files, I assume when you look at /etc/fstab and at the GRUB configuration, you will cover the most (important) ones.
I am not sure if you understand this Bob but by using a third medium, you can bit by bit clone partitions to a drive, then resize the partitions then bit-by-bit clone once again to go back to a medium.
I am sure that expanding a file system by putting some more inodes in the new space and coupling these to the chain of free inodes and coupling the new free disk blocks to the chain of free disk blocks is far more easy then moving all sorts of disk blocks from space that is to be evacuated to free blocks in the part of the file system that is to be kept and then adapting all sorts of chains and other administration (and im the mean time hoping everything will fit in the reduced space).
And remember that that should be done in a way that e.g. a power failure will still present an uncorrupted file system after power restore. No, not an obvious task to program. And in my memory shrinking of a file system was either one of the latest features added to a new file system type, or never implemented. And when implemented, system managers often tried to avoid it’s usage: stories of (fatal) failures were around.
Personaly, I still do not trust file system shrinking (yes, I am an old hand and probably still frustrated by nights of extra reparing/restoring work after such a failure). I rather copy the whole tree of the file system (tare) and restore it after reorganising the volumes.
I have already saved the fstab by making a copy from the installation and restored it after restoring the fullback backup - booted up to login screen okay as stated in original topic. When restoring the boot files my research indicates I may have to do a grub mkconfig and grub2-install (I assume that reloads the MBR which is not part of any file system). i’m also wondering if I need to do anything special with UEFI files under /boot that is not part of the file system, such as rebuild something. Also, I have seen references to mkinitrd but I think that only changes when the kernel or modules change.
It would be nice is there was a detail document on all the things that go on during a UEFI boot.
The partition that is being shrunk is /home and it has plenty of unused space. The procedure is to use xfsdump to another disk, then recreate the partition at the smaller size, and then use xfsrestore to repopulate the file.
If memory serves me correctly, I seem to recall shrinking ext4 with no problems. I prefer the copy-on-write file system since power failure does not corrupt the system and also you can rollback changes is need be.
I understood. I prefer a file and directory backup like borgbackup which offers compression, deduplication and very fast.
The SSD’s currently on my system are only 512k. Also the filesystem will need to be resized before the partition resize
on a shrink operation and in the reverse order on an expand operation.
Most FS have a shrink function but it is always dangerous since it needs to move any used block in the section to be removed to a safe location, assuming there is room. But XFS does not have such a function. So you have to recreate the partition at smaller size, reformat and restore from external backup. If the partition is recreated it will get a new UUID and thus there may be boot problem until the new partition is added to the fstab