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
Frequent loss data in GPT system
Re: Frequent loss data in GPT system
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?
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
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
Re: Frequent loss data in GPT system
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?
Re: Frequent loss data in GPT system
if you have a homogeneous set of computers, it could be a firmware bug...
Re: Frequent loss data in GPT system
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
...
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
...