Frequent loss data in GPT system

Issues related to applications and software problems and general support
Post Reply
easywork
Posts: 2
Joined: 2022/11/24 21:29:00

Frequent loss data in GPT system

Post by easywork » 2022/11/24 21:33:31

I have managed Linux servers for more than 15 years and I have never seen anything like this: After installing a 3Tb data only disk, after a few months 95% of the data simply disappeared. Another new 4 Tb HD was installed, formatted and days later the same thing happened, almost everything disappeared overnight. Suspicious of the EXT4 file system, the disk was formatted in XFS and less than 24 hours everything was gone again. During this process, the CentOS version, the CPU and a disk were changed. The issue occurred in all scenarios. I gave up and installed a Windows Server

The possibility of a virus was ruled out as the data disappeared when all stations were off and nothing was trashed

My last suspicion is the fact that the machine has a small disk (msdos) for system and a large disk (GPT) for data

User avatar
TrevorH
Site Admin
Posts: 33191
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Frequent loss data in GPT system

Post by TrevorH » 2022/11/24 22:43:42

Unless you are using some non-GPT aware partitioning tool afterwards, or maybe to create the GPT label and partitions in the first place, I think it is unlikely that it has anything to do with GPT. Or your system is really really ancient, like CentOS 4 or something. GPT has been around for a long time and is required on any disks > 2TB in size so if it was a problem, it would be known.

Don't use fdisk, it has beta support for GPT and it shows. Use gdisk or parted.

And when you say "disappeared" do you mean the partitions were still present but the data was gone? Or the filesystem? Or were both partitions and filesystems still present but the files themselves went away?
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

User avatar
jlehtone
Posts: 4523
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Frequent loss data in GPT system

Post by jlehtone » 2022/11/25 09:47:26

easywork wrote:
2022/11/24 21:33:31
The possibility of a virus was ruled out as the data disappeared when all stations were off
In other words, your observations were:
1. Machine on, data exists
2. Machine shuts down
3. Machine is off
4. Machine boots
5. Machine on, no data
How can you tell that this occurred on step 3 and not on 2 or 4?

Where was the filesystem mounted to?

BShT
Posts: 583
Joined: 2019/10/09 12:31:40

Re: Frequent loss data in GPT system

Post by BShT » 2022/11/25 11:38:46

if you have a homogeneous set of computers, it could be a firmware bug...

easywork
Posts: 2
Joined: 2022/11/24 21:29:00

Re: Frequent loss data in GPT system

Post by easywork » 2022/11/25 13:12:13

The machine was turned on and the data disappeared, but the file system was preserved without fail.

I don't remember how the partition was created, probably with cfdisk

There can be firmware on two disks and two different machines. CentOS 7 and Stream 9 were used.

The disk was mounted either manually at boot or in /etc/fstab. The problem occurred in both cases.

The last log is:
[ 190.219993] XFS (sda1): Mounting V5 Filesystem
[ 191.443381] XFS (sda1): Starting recovery (logdev: internal)
[ 225.551546] XFS (sda1): Ending recovery (logdev: internal)
[17257.728584] perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[19050.095143] traps: rpcd_classic[7616] general protection fault ip:7f2682bc0d77 sp:7ffc0c555b68 error:0 in ld-linux-x86-64.so.2[7f2682bbf000+26000]
[41717.128362] dnf[13015]: segfault at 7fa04f7e0e0c ip 00007fa023ab258b sp 00007ffdd34e3768 error 4 in libc.so.6[7fa023a1e000+175000]
[41717.128385] Code: f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa c4 41 01 ef ff 89 f8 09 f0 c1 e0 14 3d 00 00 00 f8 0f 87 25 03 00 00 <c5> fe 6f 07 c5 fd 74 0e c5 85 74 d0 c5 ed df c9 c5 fd d7 c9 ff c1
[46754.187599] traps: dnf[289148] general protection fault ip:7f8dd7cf7805 sp:7fffe9bf2d20 error:0 in libpython3.9.so.1.0[7f8dd7c4a000+1b5000]
[48626.728363] systemd-journald[847]: Failed to write entry (23 items, 714 bytes), ignoring: Cannot assign requested address
[48626.728482] systemd-journald[847]: Failed to write entry (23 items, 696 bytes), ignoring: Cannot assign requested address
[48626.728578] systemd-journald[847]: Failed to write entry (23 items, 746 bytes), ignoring: Cannot assign requested address
[48626.728672] systemd-journald[847]: Failed to write entry (23 items, 704 bytes), ignoring: Cannot assign requested address
...

Post Reply