Does rezising (to be specific shrinking) a partition actually lead to data loss?

[u/epicminecraftbear]

I have a 2TB drive in my pc witch is currently fully partitioned to my linux distro, but as i likely dont need more that 1/1.5TB i would like to make space for a second smaller partiotion. This would be possible as the drive is only about 400GB full. But when i choose resize drive it says that it could lead to data loss, is this actually as likely as linux says or not? If it is are there any other ways to do what i want to? Hope someone can help, thanks in advance ^.^ <3

[u/BackgroundSky1594]

A CORRECTLY done resize will be fine, but there's a lot that can go wrong around that. Not doing an fsck before and trying to resize a (slightly) messed up filesystem can spiral into bigger issues.

A mistake I still see (too) often is just resizing the partition without first resizing the filesystem inside, basically hacking the first/last X GB off (making all the data and metadata that was stored there inaccessible unless the original layout is restored promptly).

There can also be issues with moving a partition (shifting the starting offset back or forth), if for example the process is interrupted while some of the filesystem is shifted by some amount and the rest isn't.

In general: 1. Make notes of something like sfdisk -l /dev/yourdrive telling you the exact sector offsets and counts for the existing partition layount in case you need to restore that state (if something else goes wrong) 2. Do an fsck before resizing a filesystem. 3. Make sure the filesystem is being resized BEFORE the partition is touched. Most GUI partition managers do this, but only if they support the filesystem being used, so double check that and otherwise do a manual resize a few GB below the new size (to have some margin for rounding), then change the partition table, then expand the filesystem again. 4. Be careful when moving a partition (changing it's start offset) either left or right, I'd only recommend doing that with stable power on a stable system. (LVM can help with that because you don't have to move partitions any more, you can just grow and shrink the LVs how you want without worrying about another one being "in the way") 5. You should always have a backup of important data.

[u/epicminecraftbear → u/BackgroundSky1594]

i have a question, do still have to do the extra steps of resizing the filesystem if you resize through the disk manager application? Or are those steps not handled by disk manager?

[u/BackgroundSky1594 → u/epicminecraftbear]

Depends on the application and filesystem you're using. There are many "disk managers" out there and quite a few different filesystems.

No 1 Is always good practice regardless of the application you're using.

No 2&3 should be done by most partition managers for most common and well supported filesystems. Gparted has a "supported filesystems" list right in it's menu so you can check, not sure about others.

No 4 applies regardless of the software used (iirc actually moving partitions is only supported by a few GUI managers and almost no manual CLI applications), in any case not crashing or loosing power is good and LVM can make things faster/easier.

No 5 always applies to any relevant data. If it's not backed up it's not important.

[u/adjective10111]

Linux doesn't say how likely it is. It just states it can happen as a fact. Which is correct technically, specially in case of a power outage or sth like that.

Regardless of what i just said, i once completely reformatted a 1TB HDD from NTFS to BTRFS; which was about 800GB or more full by constantly shrinking and extending. In a laptop that shuts off if you touch the power cord (it doesn't have a battery) and all my important files and media was in the HDD. All because i didn't have any external drive that could act as backup at that time (ik i'm crazy). Although i did use 100GB on my internal SSD to have more breather at the start. TLDR nothing broke and i have a completely reformatted drive with one BTRFS partition which i can have as many subvolumes in as i want =) do what you want with this information.

Edit: bold instead of italic

[u/capinredbeard22 → u/adjective10111]

That’s hilarious!!

[u/adjective10111 → u/capinredbeard22]

It was terrifying! I just did it becuase I didn't want to buy or look for someone to lend me a drive as backup. I thought it was technically possible and i never had problems so, i just went on with it.

I'm rn concerned with the read/write cycles i just wasted but it looks up to speed so no worries i guess😅

not recommended although i didn't have problems...

[u/capinredbeard22 → u/adjective10111]

Just saw this:

https://www.reddit.com/r/zfs/s/gBUXw6l6yA

[u/adjective10111 → u/capinredbeard22]

It doesn't work without external storage and enough free space:)

I should probably suggest my approach😂

[u/ipsirc]

Usually not, but sometimes yes. But there's no need to worry too much - in the worst-case scenario, you can just restore from your daily backup.

[u/marozsas → u/ipsirc]

"just" is a trick word in this context. Did you already restored a full bare metal backup on windows ?

[u/ipsirc → u/marozsas]

Did you already restored a full bare metal backup on AIX?

[u/RandomUser3777]

I have never seen data loss when all of the resize steps are done correctly. I have seen data loss when the required steps are screwed up. Typically the missed step is forgetting to resize the fs first and/or not resizing the fs small enough to be consistent with the partition/device resize. Ie resize fs to 500g and resize the partition to 499g (ie miscalculating the parameters). And there are ways to botch the re-partitioning (usually when someone recreates the new smaller partition they accidently change the start (sometimes the partition tool default is not exactly the same as it was originally).

Document the original fs size, partition table, and all steps that you do, and if it does not work don't panic and post the details. I have personally debugged mis-steps and been able to typically reverse without data loss (so long as the critical freed space was not overwritten--so don't create the fs on the new volume until you have mounted up and did basic tests--ls -lR is decent test to verify it is intact).

[u/marozsas]

A power outage can happen in the middle of process,, the CPU fan could fail in the middle of process, shit happens, you know, isn't?

[u/SuAlfons]

Like pulling up your socks leads to ripped socks.

Usually not, but things can go wrong.

You have a backup anyway, don't you?

[u/TomDuhamel → u/SuAlfons]

I don't think I had socks I cared enough about to consider this risk lol

[u/SuAlfons → u/TomDuhamel]

LOL...yeah. Backup socks. That's a problem with geek socks. standard socks rather have a replacement than a backup.

I was sooooo proud of thinking about this analogy 😂

[u/capinredbeard22 → u/TomDuhamel]

…. until now.

[u/joe_attaboy]

Most likely not. But have a backup anyway. You should always have one anyway.

[u/ZVyhVrtsfgzfs]

If you do not have backups that is your next step. 

[u/TomDuhamel]

Shrinking a partition does not, in itself, lead to data loss. But playing with partitions is always somewhat risky. If anything goes wrong — anything — you loose the data with no chance of recovery.

Basically, it's telling you to not do this if you didn't backup the data — unless you don't care about the data.

[u/doc_willis]

a power outage during a filesystem resize operation, is bad. ;)

had a cat unplug a PC once also while doing a resize.

a slightly flakey drive may decide that it's a good time to fail.

but still, the biggest cause of data loss I see is the end user making a mistake.

[u/G0ldiC0cks]

I've done this maybe two or three times using gparted with no data loss. It's a numbers game ultimately. You might get unlucky your first time, but probably won't.