The alternative option if you were building from scratch would be virtualization. OS upgrades eventually catch up to you otherwise. IMO you're overall better off building a new configuration that's better understood and replicable, than carrying cruft around until it all finally falls apart. And yes, I know that you probably don't have that configuration and info, because it was set up over the course of months or years, and is now a mystical device. The plan for failed bare metal being "reinstall and redeploy". media server: similar situation to SMB server.Īnd then configuration is handled via a combination of "documentation" and "ansible" or similar.(Seriously, filesystem level backups of online databases are dicey) Another process puts that somewhere safe. mysql dumps itself to a backup file, probably via automysqlbackup.Samba is on a snapshot filesystem, with snapshots exported (and that doubles as a nice option for rollback in case of deletion or ransomware).The "preferred" option for that kind of stuff would probably be: I've certainly done that process to migrate to new hardware, but prefer to do a fresh start if possible. Additionally, recovering to another system would. Mirroring the disk is preferred for that presumably you have a PERC, but I don't believe you can convert a single disk to RAID using that. That kind of process usually isn't the best for RPO though. It's technically possible to duplicate your entire disk to another one. There's a reason enterprise has significantly moved towards a combination of application-level backups and virtual infrastructure. that's a rather painful situation to try to back up. If you're recovering to new filesystems, you'll have to update /etc/fstab and /etc/crypttab, run an grub-install and update-grub. If you want to roll back the source machine, just add -delete to the rsync and run it in the other direction (I usually do live restores from a busybox shell, systems get a little wonky when you nuke some of the core libs while it's running). Whole system recovery is pretty simple, and if you're going back to the original host, about zero config. After you do my suggested bind mount, compare /dev/ and /mnt/root/dev/ as well as /sys/ and /mnt/root/sys/. A bind mount lets your kind of get 'under' mounted paths on a filesystem. Doing the bind mount two step lets you omit that ugly -exclude, and also some of those excluded files have static files underneath them you actually need if you're going to create another running system. Of course, you need your backup to already be mounted on /mnt/root_backup, they just had it on /mnt in those instructions. Then rsync -HAXhaxvPS -stats -numeric-ids /mnt/root/ /mnt/root_backup/. What I do is similar, however, I first rsync the /boot filesystem to the root filesystem in a locations like /.boot.bak/. That's almost a good howto, recovering a running system would be difficult.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |