Issue Migration & Transfer Manager, no space left

[JogoVogo]

Server operating system version

Plesk Obsidian v18.0.50_build1800230213.12

Plesk version and microupdate number

os_CentOS 7

Hello all,

While moving to another datacenter with Plesk Migrator, we encountered the following problem, on a new Plesk server with 500 GB of disk space, it "ran" full to the brim.

It is no longer possible to log in Plesk.

The target server has a fresh Cento 7 installation with Plesk, so about 480GB of free disk space.

The original Plesk server but only about 360 GB occupied, how can this be and what can I do?

Thanks in advance!

 

[Kaspar]

Hard to say why your disk space filled up. But needless to say you'll need to free up some space to get Plesk running again. You can use the df -h command to see which directories are the largest and descent from there to see if you can find anything you can remove.

 

[JogoVogo]

Here is the problem...

Can't really assign that.
Must be related to the back-up.

We backup only on external ftp, incremental, every day at 10am.
But the migration ran well after the backup, overnight.

On the source server there are the files too, but together they are only about 2 GB.

 

[Peter Debik]

Local backup files are not migrated. These files must be located somewhere inside a subscription so that they were migrated from there. But if they make up only 2 GB, the cause is probably something different.

 

[JogoVogo]

I have searched the whole server and there are no other files of this type.

We have moved servers several times, but I have never had this phenomenon.

 

[Peter Debik]

From the / level, please run
# du -hs * | sort -h > filesizes.txt
It will take a long while to complete, but will give you a list of all directories and files sorted by size in filesizes.txt. From there it should be easy to find where the big data is hidden.

 

[JogoVogo]

You see lib, only 2GB, on target it was 141GB.

 

[Peter Debik]

So we see that the source was already filled with 350 GB. But the source is not the problem, right? When you know that on the target /lib is 141 GB, have you considered looking into that path to find out what occupies these 141 GB on the target?

 

[JogoVogo]

That's right.
But exactly the files in /lib fill up the new server with 141 GB.

On the source server there are the files as well, but there they are only 2 GB.

 

[Peter Debik]

According to your screenshot, the screenshot is not from /lib, but from /var/lib/psa/dumps. What is the output of
# pwd
?
I suppose that the files you are showing are temporary files from Migrator. If these *.tar files are not needed by you, you can probably just delete them (if Migration was completed successfully). However, if your target server does not have enough space for temporary migration files, you need to either change the PMM temp paths to another partition or add a disk or upgrade disk space. This KB article describes how to move the /psa/dumps directory to a different location (off your partition in your case): https://support.plesk.com/hc/en-us/...tion-for-Plesk-backup-files-on-a-Linux-server

 

[JogoVogo]

this is already var/lib/psa

as already mentioned we have done the migration before, it was never a problem, with almost identical setup.

Unfortunately there is no possibility to use another device, at the destination

Are you sure that the dumps are created during migration?

 

[JogoVogo]

The new machine is done, this is the available space.

Should I perhaps turn off the back-up on the source machine before migrating?

 

[Peter Debik]

Local backups are not part of a migration. The only reason for backup files on the target can be that they result from the migration. Plesk Migrator is the same software that is used for backup and restore. It uses the same algorithms, just the overall handling with moving the packages to another server is a bit different.

 

[mow]

Plesk Migrator is the same software that is used for backup and restore. It uses the same algorithms, just the overall handling with moving the packages to another server is a bit different.

I thought it uses rsync?

 

[JogoVogo]

I thought it uses rsync?

I also understood that...

We have the identical scenario already, there it went without problems.

What does it mean now that the server must have at least 25% more disk space available than on the original one.

For most migrations not so ideal.

 

[JogoVogo]

A binding statement would be helpful here, as we need to get this over the line by March 27.

 

[Peter Debik]

I thought it uses rsync?

Yes, but it does not copy content file by file as that is not possible. Think about databases for example.

 

[Peter Debik]

A binding statement would be helpful here, as we need to get this over the line by March 27.

What kind of binding statement do you expect? If you have files in the dumps directory that are not created by a local backup, neither the daily system dumps, what keeps you from removing them to free space?

 

[JogoVogo]

Question is what can I do so that I have at the finish with once these huge files that were not there before, and 140 GB more than the source consume.

With the previous migration this was never the case

 

[Peter Debik]

As mentioned before, I think these are temporary files from the migration that can be deleted. But as others or me can only guess on the files maybe it is best if you open a support ticket so that support staff can check this directly on your server. They will be able to definitely tell from where these files come, why they are there and what to do with them.

How to get support directly from Plesk?

Question How to get support directly from Plesk? Answer Lease-type Plesk licenses purchased directly from Plesk running on supported Plesk version include full free support. Perpetual-type license...

support.plesk.com