Hi folks !
got an issue here and i hope 4 some help pls.

ubuntu server here
/boot is on flash drive , got it cloned on several flash drives just 4 backup

/ is on 2 x 1TB mirror mdadm (md0 ) , usage is 17G except a backup folder (600GB)

got a 120 GB ssd drive mounted on /mnt and rsynced / on it except that backup folder , /proc/* /sys/* and /mnt*

Running from raid array , i did save /boot/grub/grub.cfg somewhere , and ran update-grub

Now, looking at ssd drive entry , i see that instead ssd UUID , root is still md0 UUID.
How can I do it properly without using dd (long time and spare drive must be same size)?

All i want to accomplish is to sync weekly entire system on a secondary drive , so if system got unusable for different reasons , i can do a failsafe reboot on SSD drive, loosing only 1 week data

Change the UUID in /boot/grub/grub.cfg and fstab as well. You might also want to copy the mbr to the ssd. As well ass not backup /dev. You might also end up in the wrong spot if while you rsync some files might change and you end up with inconsistency. Best way. Boot into another (live) system. Then rsync /, dd the mbr, edit fstab and grub.cfg. Then reboot into original system.

Thanks zhjim 4 quick reply !
Indeed , seems like it needs manualy change UUID in grub.cfg wich i do not seem right , update-grub should add new drive UUID auutomaticaly , no ?

cloning mbr is not an issue here as long /boot resides on external flash drive

I can do manually update grub ,but in this case i should rsync --except /etc/fstab in order not to return to previous case .
anyway , i gotta do some further investigations in order to do a proper entire system back-up

Thank you !

Not sure about the internals of update-grub but i doubt that it will change UUID of root devices if it still finds existing one. You might try to chroot into your ssd backup and run update-grub there. Might change the uuid. Definitely checkout /boot/grub/device.map.

A good approach is to have rsync scripts that run more-or-less constantly, sending the data to a directory on the backup drive which is write-protected, accessible only to the special user-id that's responsible for backups. This is basically how Apple's Time Machine operates. There are a number of good web pages that show how the trick is done.

For instance, this one: https://bipedu.wordpress.com/2014/02...-time-machine/

And, leave us not forget this site! http://www.linuxquestions.org/questi...achine-889376/ (There are numerous really good links in that thread.)

For recovery purposes, then, you need a bootable CD-ROM ("sticks" can fail or be modified ...) that can be used to launch a recovery system, to perform filesystem tests and repairs, and so forth.

But, to be any good at all, the backups must be detailed and very current. "A week old" is useless.

From time to time, you should make a snapshot of the backup drive, take it to another machine altogether (which is not connected to the Internet), and "do a complete 'fire drill.'" The scenario is this: that "the worst has just happened," this machine is your replacement device, and your job is to completely and accurately restore the system onto it within two hours, and to demonstrate that the procedure worked. These days, I would use a phone to film the exercise.

2 members found this post helpful.