Backup Linux and restore it on another hardware
I work in an organization with a small staff, the activity is closely related to IT and we have tasks in system administration. I find this interesting and often I take the decision of some.
Last week we set up FreePBX under debian 7.8, hired a freelancer. In the process of setting up, it turned out that the server (yes, I call it the usual PC) does not want to boot from the HDD when USB 3G modems are connected, which we use to make calls to mobiles, the BIOS humbing did not help. Disorder. I decided that I need to transfer it to another piece of iron. So two related tasks appeared at once:
Googling did not give clear answers, how to do it, I had to collect information in pieces and try. Any acronis'y rejected immediately, because it is not interesting.
')
I have little experience with linux systems: setting up a VPN server on an open-vpn, ftp server, and a couple more trifles. I characterize myself as someone who can read mana and edit configs :)
Below I describe my particular case and why I did just that. I hope it will be useful for newbies, and bearded admins will smile at the memory of their youth.
On creating backups of a lot of articles, I noted for myself two ways: tar - packs and compresses all files, but the MBR is not saved, my backup will weigh about 1.5 Gb; dd - makes a complete copy of the partition, including the MBR and the entire area where there are no files, the archive will be equal to the size of the partition, in my case ~ 490 Gb.
The second method requires an external hard disk not less than the volume that is being archived. And what to do with it then, it is not clear, to store on the shelf? I stopped at tar, a little harder to implement, you will need to create an MBR, but the time to create / restore the archive is significantly less, you can keep the backup easier, you can upload one and a half gig to the cloud and download it when needed. You can record it on the same live-flash drive with which I will boot.
Boot from the live flash drive, I have this debian-live-7.8.0-amd64-standard.
Switch to root:
We are mounting the partition that we will archive, I have this sda1, in order not to accidentally break the wood, we mount it only for reading. You can view all your partitions with the help of the commands ls / dev | grep sd or df -l
Our flash drive is already mounted, but in read-only mode, you need to remount to read-write in order to write a backup there.
Everything is ready to create an archive
Here we have the parameters: c - create an archive, v - display information about the process, z - use gzip compression, p - save data about the owners and access rights, f - write the archive to a file, file path, --exclude - exclude from the archive directory (I excluded directories with conversations and the directory with FreePBX backups), / mnt / is the directory that we archive.
We are waiting ... all the preparation and creation of the archive took me 10 minutes. If it were a flash drive, it would have been better in 7-8 minutes.
Unmount the disk:
... and reboot.
We put the archive in a safe place outside the office.
Boot from the live flash drive, I still have the same debian-live-7.8.0.
Switch to root:
Mark up the drive. I liked the cfdisk pseudo-graphical utility. Everything is simple and clear.
Delete all available sections. I created two new partitions, one for 490 Gb under / (sda1) and 10 Gb for swap (sda2) at the end of the disk, since it will practically not be involved. Check the partition types. Which under the system must have type 83 Linux, the second - 82 Linux swap / Solaris. Mark the system partition bootable (bootable), save the changes and exit.
Create a file system on the first partition.
Mount the formatted partition
Unpack the archive directly from the flash drive
The parameter —same-owner — saves the owners of the files being unpacked, x - extracts from the archive, v - displays information about the process, p - saves access rights, f - specifies the file that we unpack, C - unpacks into a category.
To correctly create a boot record, mount the working directories to our future root directory, I have this / mnt. The / dev and / proc directories are now used by the live system, using the bind parameter so that they are available in two places at once:
Switch to the new system using chroot:
Making a swap partition for the new system:
We connect it:
In order for grub to work, you need to specify the correct UUID of the partitions in fstab, now there are sections of the previous system:
Open the second terminal (Alt + F2) as root:
Call:
And see the current UUID sections.
Manually rewrite them in fstab by switching between Alt + F1 and Alt + F2. Yes, it's a chore, but trying to copy took me more time than rewriting. Save fstab.
Install grub2. I have one physical disk, so we put it on sda:
On a blank disk should get up without errors. Update information from fstab:
We return to the live-system:
Unmount all directories:
If the processes that use these directories come out, we kill them using fuser.
Everybody, let's go. Boot from hard disk:
Here the article was supposed to end, but I had problems with connecting to the Internet. The server sees the network, sees the computers in it, but does not go to the Internet ... and this seems to be important for telephony.
It shows the interfaces eth1 and lo, googling said that the gateway can be registered only to the eth0 connection, the rest are designed only for work inside the network.
It seems that the lack of eth0 is caused by the way the system is transferred. Find the file that is responsible for the numbering of interfaces, look there:
Indeed, there are two active interfaces defined by the MACs. We comment the first, we register to the second eth0.
Restarting /etc/init.d/networking did not help, so we reboot:
We connect the dongles, check, everything works.
Thanks for attention.
Last week we set up FreePBX under debian 7.8, hired a freelancer. In the process of setting up, it turned out that the server (yes, I call it the usual PC) does not want to boot from the HDD when USB 3G modems are connected, which we use to make calls to mobiles, the BIOS humbing did not help. Disorder. I decided that I need to transfer it to another piece of iron. So two related tasks appeared at once:
- make a backup server;
- restore backup on another gland.
Googling did not give clear answers, how to do it, I had to collect information in pieces and try. Any acronis'y rejected immediately, because it is not interesting.
')
I have little experience with linux systems: setting up a VPN server on an open-vpn, ftp server, and a couple more trifles. I characterize myself as someone who can read mana and edit configs :)
Below I describe my particular case and why I did just that. I hope it will be useful for newbies, and bearded admins will smile at the memory of their youth.
We start to dig theory:
On creating backups of a lot of articles, I noted for myself two ways: tar - packs and compresses all files, but the MBR is not saved, my backup will weigh about 1.5 Gb; dd - makes a complete copy of the partition, including the MBR and the entire area where there are no files, the archive will be equal to the size of the partition, in my case ~ 490 Gb.
The second method requires an external hard disk not less than the volume that is being archived. And what to do with it then, it is not clear, to store on the shelf? I stopped at tar, a little harder to implement, you will need to create an MBR, but the time to create / restore the archive is significantly less, you can keep the backup easier, you can upload one and a half gig to the cloud and download it when needed. You can record it on the same live-flash drive with which I will boot.
So, the plan of action:
- create backup;
- formatting, partitioning the disk, creating a file system;
- restore backup;
- creating an MBR;
- testing and troubleshooting.
1. Creating a backup
Boot from the live flash drive, I have this debian-live-7.8.0-amd64-standard.
Switch to root:
sudo su We are mounting the partition that we will archive, I have this sda1, in order not to accidentally break the wood, we mount it only for reading. You can view all your partitions with the help of the commands ls / dev | grep sd or df -l
mount -o ro /dev/sda1 /mnt Our flash drive is already mounted, but in read-only mode, you need to remount to read-write in order to write a backup there.
mount -o remount,rw /dev/sdb1 /lib/live/mount/medium Everything is ready to create an archive
tar -cvzpf /lib/live/mount/medium/backupYYYYMMDD.tgz --exclude=/mnt/var/spool/asterisk/monitor --exclude=/mnt/var/spool/asterisk/backup /mnt/ Here we have the parameters: c - create an archive, v - display information about the process, z - use gzip compression, p - save data about the owners and access rights, f - write the archive to a file, file path, --exclude - exclude from the archive directory (I excluded directories with conversations and the directory with FreePBX backups), / mnt / is the directory that we archive.
We are waiting ... all the preparation and creation of the archive took me 10 minutes. If it were a flash drive, it would have been better in 7-8 minutes.
Unmount the disk:
umount /mnt ... and reboot.
reboot We put the archive in a safe place outside the office.
Restoring backup on another gland
2. We mark a disk, we create file system
Boot from the live flash drive, I still have the same debian-live-7.8.0.
Switch to root:
sudo su Mark up the drive. I liked the cfdisk pseudo-graphical utility. Everything is simple and clear.
cfdisk Delete all available sections. I created two new partitions, one for 490 Gb under / (sda1) and 10 Gb for swap (sda2) at the end of the disk, since it will practically not be involved. Check the partition types. Which under the system must have type 83 Linux, the second - 82 Linux swap / Solaris. Mark the system partition bootable (bootable), save the changes and exit.
Create a file system on the first partition.
mkfs.ext4 /dev/sda1 3. Unpack the archive.
Mount the formatted partition
mount /dev/sda1 /mnt Unpack the archive directly from the flash drive
tar --same-owner -xvpf /lib/live/mount/medium/backupYYYYMMDD.tgz -C /mnt/ The parameter —same-owner — saves the owners of the files being unpacked, x - extracts from the archive, v - displays information about the process, p - saves access rights, f - specifies the file that we unpack, C - unpacks into a category.
4. Create an MBR on a new disk.
To correctly create a boot record, mount the working directories to our future root directory, I have this / mnt. The / dev and / proc directories are now used by the live system, using the bind parameter so that they are available in two places at once:
mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc Switch to the new system using chroot:
chroot /mnt Making a swap partition for the new system:
mkswap /dev/sda2 We connect it:
swapon /dev/sda2 In order for grub to work, you need to specify the correct UUID of the partitions in fstab, now there are sections of the previous system:
nano /etc/fstab Open the second terminal (Alt + F2) as root:
sudo su Call:
blkid And see the current UUID sections.
Manually rewrite them in fstab by switching between Alt + F1 and Alt + F2. Yes, it's a chore, but trying to copy took me more time than rewriting. Save fstab.
Install grub2. I have one physical disk, so we put it on sda:
grub-install /dev/sda On a blank disk should get up without errors. Update information from fstab:
update-grub We return to the live-system:
exit Unmount all directories:
umount /mnt/dev umount /mnt/proc umount /mnt If the processes that use these directories come out, we kill them using fuser.
Everybody, let's go. Boot from hard disk:
reboot Here the article was supposed to end, but I had problems with connecting to the Internet. The server sees the network, sees the computers in it, but does not go to the Internet ... and this seems to be important for telephony.
5. Testing and troubleshooting.
ifconfig -a It shows the interfaces eth1 and lo, googling said that the gateway can be registered only to the eth0 connection, the rest are designed only for work inside the network.
It seems that the lack of eth0 is caused by the way the system is transferred. Find the file that is responsible for the numbering of interfaces, look there:
nano /etc/udev/rules.d/70-persistent-net.rules Indeed, there are two active interfaces defined by the MACs. We comment the first, we register to the second eth0.
Restarting /etc/init.d/networking did not help, so we reboot:
reboot We connect the dongles, check, everything works.
Thanks for attention.
Source: https://habr.com/ru/post/251659/
All Articles