In Centos 6 / Windows 10 dual boot, overwritten partition by Windows bootloader
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
In a previous Centos 6 install, Windows 10 was installed months ago and the Centos 6 GRUB file was updated to select dual boot by disk name.
Recently, due to some kind of error in a reboot, the disk order was changed and Windows tried to boot from an array partition (which contained no OS, only data), destroying it and just leaving a 150 something Mb boot partition where there was a full disk XFS partition.
Now I have that array in this state:
GUID partition table
+150 something Mb NTFS file system (presumably the Windows boot partition that destroyed the previous partition)
+10 Tb empty space
I am sure the disk was overwritten by Windows boot and I need to restore the previous partition and access the previous data, but I'm doubting which is the best procedure in this case:
a) Should I delete the NTFS boot partition and try a full testdisk disk recovery?
b) Should I delete the NTFS boot partition and use fdisk or similar to automagically restore the previous partition?
c) Should I use low-level recovery software to try to recover as much raw data as possible since all hope of a clean restore is gone?
grub2 dual-boot data-recovery boot-loader
asked Nov 6 '17 at 14:12
A. del Solar
1
add a comment |Â
up vote
0
down vote
favorite
In a previous Centos 6 install, Windows 10 was installed months ago and the Centos 6 GRUB file was updated to select dual boot by disk name.
Recently, due to some kind of error in a reboot, the disk order was changed and Windows tried to boot from an array partition (which contained no OS, only data), destroying it and just leaving a 150 something Mb boot partition where there was a full disk XFS partition.
Now I have that array in this state:
GUID partition table
+150 something Mb NTFS file system (presumably the Windows boot partition that destroyed the previous partition)
+10 Tb empty space
I am sure the disk was overwritten by Windows boot and I need to restore the previous partition and access the previous data, but I'm doubting which is the best procedure in this case:
a) Should I delete the NTFS boot partition and try a full testdisk disk recovery?
b) Should I delete the NTFS boot partition and use fdisk or similar to automagically restore the previous partition?
c) Should I use low-level recovery software to try to recover as much raw data as possible since all hope of a clean restore is gone?
grub2 dual-boot data-recovery boot-loader
asked Nov 6 '17 at 14:12
A. del Solar
1
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In a previous Centos 6 install, Windows 10 was installed months ago and the Centos 6 GRUB file was updated to select dual boot by disk name.
Recently, due to some kind of error in a reboot, the disk order was changed and Windows tried to boot from an array partition (which contained no OS, only data), destroying it and just leaving a 150 something Mb boot partition where there was a full disk XFS partition.
Now I have that array in this state:
GUID partition table
+150 something Mb NTFS file system (presumably the Windows boot partition that destroyed the previous partition)
+10 Tb empty space
I am sure the disk was overwritten by Windows boot and I need to restore the previous partition and access the previous data, but I'm doubting which is the best procedure in this case:
a) Should I delete the NTFS boot partition and try a full testdisk disk recovery?
b) Should I delete the NTFS boot partition and use fdisk or similar to automagically restore the previous partition?
c) Should I use low-level recovery software to try to recover as much raw data as possible since all hope of a clean restore is gone?
grub2 dual-boot data-recovery boot-loader
asked Nov 6 '17 at 14:12
A. del Solar
1
In a previous Centos 6 install, Windows 10 was installed months ago and the Centos 6 GRUB file was updated to select dual boot by disk name.
Recently, due to some kind of error in a reboot, the disk order was changed and Windows tried to boot from an array partition (which contained no OS, only data), destroying it and just leaving a 150 something Mb boot partition where there was a full disk XFS partition.
Now I have that array in this state:
GUID partition table
+150 something Mb NTFS file system (presumably the Windows boot partition that destroyed the previous partition)
+10 Tb empty space
I am sure the disk was overwritten by Windows boot and I need to restore the previous partition and access the previous data, but I'm doubting which is the best procedure in this case:
a) Should I delete the NTFS boot partition and try a full testdisk disk recovery?
b) Should I delete the NTFS boot partition and use fdisk or similar to automagically restore the previous partition?
c) Should I use low-level recovery software to try to recover as much raw data as possible since all hope of a clean restore is gone?
grub2 dual-boot data-recovery boot-loader
asked Nov 6 '17 at 14:12
A. del Solar
1
asked Nov 6 '17 at 14:12
A. del Solar
1
asked Nov 6 '17 at 14:12
A. del Solar
1
asked Nov 6 '17 at 14:12
A. del Solar
1
1
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16
add a comment |Â
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
The best procedures to recover files in xfs appear to be:
xfs_repair - Link to documentation
Included or downloadable in several GNU/Linux distributions.xfs_check /dev/device --> Analyze the disk (no writing)
xfs_repair -n --> A more in-depth analysis (no writing)xfs_repair --> Actual recovery (writing)
testdisk - Link to documentation
Free software included in Gparted.Follow the steps in the documentation link.
UFS Explorer - Link to product
Commercial proprietary software.Recovery with user friendly GUI, could work if 1. and 2. fail.
answered Nov 13 '17 at 13:53
A. del Solar
1
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The best procedures to recover files in xfs appear to be:
xfs_repair - Link to documentation
Included or downloadable in several GNU/Linux distributions.xfs_check /dev/device --> Analyze the disk (no writing)
xfs_repair -n --> A more in-depth analysis (no writing)xfs_repair --> Actual recovery (writing)
testdisk - Link to documentation
Free software included in Gparted.Follow the steps in the documentation link.
UFS Explorer - Link to product
Commercial proprietary software.Recovery with user friendly GUI, could work if 1. and 2. fail.
answered Nov 13 '17 at 13:53
A. del Solar
1
add a comment |Â
up vote
0
down vote
The best procedures to recover files in xfs appear to be:
xfs_repair - Link to documentation
Included or downloadable in several GNU/Linux distributions.xfs_check /dev/device --> Analyze the disk (no writing)
xfs_repair -n --> A more in-depth analysis (no writing)xfs_repair --> Actual recovery (writing)
testdisk - Link to documentation
Free software included in Gparted.Follow the steps in the documentation link.
UFS Explorer - Link to product
Commercial proprietary software.Recovery with user friendly GUI, could work if 1. and 2. fail.
answered Nov 13 '17 at 13:53
A. del Solar
1
add a comment |Â
up vote
0
down vote
up vote
0
down vote
The best procedures to recover files in xfs appear to be:
xfs_repair - Link to documentation
Included or downloadable in several GNU/Linux distributions.xfs_check /dev/device --> Analyze the disk (no writing)
xfs_repair -n --> A more in-depth analysis (no writing)xfs_repair --> Actual recovery (writing)
testdisk - Link to documentation
Free software included in Gparted.Follow the steps in the documentation link.
UFS Explorer - Link to product
Commercial proprietary software.Recovery with user friendly GUI, could work if 1. and 2. fail.
answered Nov 13 '17 at 13:53
A. del Solar
1
The best procedures to recover files in xfs appear to be:
xfs_repair - Link to documentation
Included or downloadable in several GNU/Linux distributions.xfs_check /dev/device --> Analyze the disk (no writing)
xfs_repair -n --> A more in-depth analysis (no writing)xfs_repair --> Actual recovery (writing)
testdisk - Link to documentation
Free software included in Gparted.Follow the steps in the documentation link.
UFS Explorer - Link to product
Commercial proprietary software.Recovery with user friendly GUI, could work if 1. and 2. fail.
answered Nov 13 '17 at 13:53
A. del Solar
1
answered Nov 13 '17 at 13:53
A. del Solar
1
answered Nov 13 '17 at 13:53
A. del Solar
1
answered Nov 13 '17 at 13:53
A. del Solar
1
1
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402838%2fin-centos-6-windows-10-dual-boot-overwritten-partition-by-windows-bootloader%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
The best approach would be simply to restore from backups.
– Andrea Lazzarotto
Nov 7 '17 at 10:17
But recovery wise, in case you don't have a backup, how would you do it?
– A. del Solar
Nov 8 '17 at 14:27
A full clone of the entire drive and then you can try Testdisk and other stuff on the clone. If you screw up badly, repeat the cloning and try again. Unfortunately I have not much knowledge about XFS, but it's safe to assume that at least important data was backed up.
– Andrea Lazzarotto
Nov 8 '17 at 22:17
Thank you, I tried Testdisk but sadly no major partition was found, only small fragments that weren't recoverable. Then I tried xfs_repair first: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… And I could recover around 200 Mb files.
– A. del Solar
Nov 13 '17 at 13:16