How to create and transfer (clone) a backup copy of the linux system drive from one VDS to another?

Vladimir2018-07-19 04:51:25

linux

Vladimir, 2018-07-19 04:51:25

Welcome all.
On the server, the system partition of the disk, there is an online store Bitrix with a lot of traffic. The question arose about backup cloning of the linux system drive from one VDS to another and then updating the system on the donor server (php, mysql, Bitrix web environment). We use the server from TimeWeb, which does not have the functions of cloning VDS, booting the system from a live CD, loading a backup copy of the drive.
What is the best way to create and transfer (clone) a backup copy of the linux system drive from one VDS to another with minimal downtime for the site?

Answer the question

In order to leave comments, you need to log in

7 answer(s)

Puma Thailand, 2018-07-19
@opium

Thank God this is Linux and you can just rsync without system files and everything will be exactly the same

CityCat4, 2018-07-19
@CityCat4

dump/restore
the clumsy way - tar everything from the root. Stupid, gluttonous, a lot of superfluous, but you certainly won’t miss anything ...

Sanes, 2018-07-19
@Sanes

It's easier and cheaper to contact TimeWeb support.
True, you can run into the sluggishness typical of large companies. Bureaucracy, regulations, etc.

Alexey Emelyanov, 2018-07-19
@babarun

https://toster.ru/answer?answer_id=426823
I will duplicate,
To choose the right strategy for migrating a site to another server, first of all, you need to decide whether it is allowed to disable write / update operations in the database during the transfer of the resource, i.e. actual simple? Let's assume that we have started the transfer of a loaded online store, where an order occurs every three minutes. If you stupidly dump the database, make a file archive, transfer it to another server, deploy the whole thing, then the time lag will be at least 30 minutes, even if the new piece of iron is in the same rack. While the transfer is taking place, new orders will already be recorded in the old database. As an option, it is possible to prohibit the creation of orders and users during the migration, but business does not like a simple 30 minutes (and actually 2 hours), therefore, seamless relocation is practiced on large projects - first, a balancer is installed, DNS is rewritten to it, and it, in turn, proxies traffic to the old server, then the second server rises, a database is deployed on it, which connects to the database on the old server as a slave, scripts are synchronized by rsync / csync, files are moved to the cloud. As a result, we get the classic master-slave model. In the end, we change the roles in the database, make the new one the master, and the old one the slave. Shutting down the old server.

t_q_l, 2018-07-19
@t_q_l

Try stage4 ( instructions )

Vladimir, 2018-07-19
@lycifep

In general, there are 2 options:
1. We rent a backup VDS. We back up the disk with tar, transfer it via ssh to a new server, and restore it. The domain is configured on a new server. When the move takes place, we synchronize the database via SQLyog. Site downtime about 30 min. On the old server, we update everything, test it. We repeat the move. Costs: rent of a new server + additional disks (for a month). The risk is minimal
2. Backup disk by means of hosting. Rolling updates, testing. When critical problems appear, we roll back. Simple with problems in more than 1 option and more risk.
Soon I will write what came of it ...

Official account of the Timeweb team, 2020-05-22
@timeweb_team

Good afternoon.
Previously, in order to transfer all the contents of the server, we performed the cloning operation in the following way:
1) Mount the backup copy in the pu.
2) Next, you need to create a VDS with the same disk size (or more) as on the transmitting server (in our case, in proportion to the backup).
3) Download the receiving server from Livecd. On the transmitter, you can execute commands directly in the OS.
In livecd mode on the receiving server, run:
nc -l -v -p 39999 | pv --size 35g > /dev/vda
# 35g is the size of the disk on the transmitting server
(pv is needed to display the progress bar)
5) On the transmitting server, run:
cat /dev/vda | nc timeweb_ip 39999
instead of timeweb_ip it should be the ip address of the receiving server
instead of /dev/vda the path to the block device (mounted backup)
In essence, these commands take the entire contents of the hard disk of one server and write it to another server.