backup drive strange filesystem markers

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

Don’t get too hasty with this. It looks like all is probably okay.

You can (in Linux) change the file permissions, and the permission changes hold?

I am just quick-glancing at the moment, but I think what you are seeing is that the utilities have not caught up completely to the recent changes in file-systems and partitioning.

As a result, even though things are okay, you are getting readouts that look odd, but are fine.

This involves the GPT partitioning.

See this:
http://www.linuxquestions.org/questions/linux-general-1/partition-codes-for-gpt-865555/

It all looks okay to me. Those partition type codes are not all that important.

My best guess is that “gparted” already put the “wrong” partition type codes there when you partitioned, but you did not notice until later.

If it were me, yes I would probably change the typecodes in “gdisk” (with the “t” command as you suggest). However, it should continue to work without that. And then there’s that old saying “If it ain’t broke, don’t fix it.”

Those actually are the correct typecodes for GPT, I believe.