I am using a dual boot Windows 8 openSUSE 13.2 Laptop (laptop #2 below).
I have purchased a backup hard drive and formatted it using gparted with
gpt formatting, and the exact same sector assignments for each
partition. I use an rsync script that I wrote to clone the system and
data partitions in Linux, with the idea that if my hard drive ever
crashes, I will just be able to take it out and put in the new one,
reboot, and be back up and running fairly quickly, and with data as good
as my most recent backup (which I do about twice a day).
When I set up my system, I made all the linux partitions on both my main
drive and the external backup to be ext4, using gparted to set them up.
Then once time, I made the mistake of booting into Windows with the
backup drive still plugged in, and it changed something on the drives. I
didn’t notice it at first, as the Yast expert partitioner shows that the
last 4 partitions on the backup are still formatted in Ext4 format, just
as on the main drive.
Also, I run my backup program at least twice every day without any
problems. The partitions mount just fine and the data syncs without any
problem.
However, once I made the mistake of booting into Windows with the backup
drive plugged in, the file types changed for those partitions, even
though I am still able to mount them and write to them as though they
are linux partitions. Here fdisk shows the filetype, with /dev/sda being
my main drive and /dev/sdb being the external I use for a backup:
# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 20EA9E38-5E0A-4565-8CD0-655FE85074D5
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 2050047 1843200 900M Windows recovery
environment
/dev/sda3 2050048 2312191 262144 128M Microsoft reserved
/dev/sda4 2312192 201336831 199024640 94.9G Microsoft basic data
/dev/sda5 201336832 232615935 31279104 14.9G Linux swap
/dev/sda6 232615936 291209215 58593280 28G Linux filesystem
/dev/sda7 291209216 349802495 58593280 28G Linux filesystem
/dev/sda8 349802496 1619333119 1269530624 605.4G Linux filesystem
/dev/sda9 1619333120 1814644735 195311616 93.1G Linux filesystem
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 64EE1DBF-538A-4DCA-B917-5FDD6F804B6B
Device Start End Sectors Size Type
/dev/sdb1 2048 206847 204800 100M EFI System
/dev/sdb2 206848 2050047 1843200 900M Windows recovery
environment
/dev/sdb3 2050048 2312191 262144 128M Microsoft reserved
/dev/sdb4 2312192 201336831 199024640 94.9G Microsoft basic data
/dev/sdb5 201336832 232615935 31279104 14.9G Linux swap
/dev/sdb6 232615936 291209215 58593280 28G Microsoft basic data
/dev/sdb7 291209216 349802495 58593280 28G Microsoft basic data
/dev/sdb8 349802496 1619333119 1269530624 605.4G Microsoft basic data
/dev/sdb9 1619333120 1814644735 195311616 93.1G Microsoft basic data
And you can see that using gdisk, it gives the actual codes:
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 20EA9E38-5E0A-4565-8CD0-655FE85074D5
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 138882413 sectors (66.2 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 206847 100.0 MiB EF00 EFI system
partition
2 206848 2050047 900.0 MiB 2700 Basic data
partition
3 2050048 2312191 128.0 MiB 0C01 Microsoft
reserved ...
4 2312192 201336831 94.9 GiB 0700 Basic data
partition
5 201336832 232615935 14.9 GiB 8200
6 232615936 291209215 27.9 GiB 8300
7 291209216 349802495 27.9 GiB 8300
8 349802496 1619333119 605.4 GiB 8300
9 1619333120 1814644735 93.1 GiB 8300
# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 64EE1DBF-538A-4DCA-B917-5FDD6F804B6B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 138882413 sectors (66.2 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 206847 100.0 MiB EF00
2 206848 2050047 900.0 MiB 2700
3 2050048 2312191 128.0 MiB 0C01
4 2312192 201336831 94.9 GiB 0700
5 201336832 232615935 14.9 GiB 8200
6 232615936 291209215 27.9 GiB 0700
7 291209216 349802495 27.9 GiB 0700
8 349802496 1619333119 605.4 GiB 0700
9 1619333120 1814644735 93.1 GiB 0700
So, I am inclined to use gdisk to simply change the codes of those last
4 partitions back to 8300. But I am wondering, will this affect the
data? Will I have to run full new backups, or will the data on those
partitions be preserved?
Also, is that really the right procedure, to just use gdisk, and the
command t for that partition, and to change it to 8300?
I just want to make sure I have done my research right before I do this,
and not erase all my data (it would take a lot of time to run full
backups again onto blank partitions).
–
G.O.
Box #1: 13.1 | KDE 4.12 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 13.1 | KDE 4.12 | AMD Athlon X3 | 64 | 4GB
Laptop #1: 13.1 | KDE 4.12 | Core i7-2620M | 64 | 8GB
Laptop #2: 13.2 | KDE 4.14 | Core i7-4710HQ | 64 | 16GB