2

I have heard if you don't make partitions in linux, it is so hard to recover the data. And if you make few partitions it would be easy to recover the data.

for example if you make /par1 /part2 /part3 it is better for recovery.

But now some of my friends tell me that /home/user/{all data here} has no difference with making /par1 /part2 /part3 concerning recovery.

Which one is true, and why?

  • I have heard if you don't make partitins in linux it is so hard to recovery your data where did you hear that? – Lie Ryan Feb 8 '15 at 10:41
5

To illustrate the question in a simple and efficient manner, consider two scenarios:

  • You install your favourite linux distribution on entire disk i.e. without any partitions:

    Suppose your system is crashed because operating system is unable to access some sectors and unable to boot. You lost some chunk of data due to bad sectors and because of that you might be unable to access other chunks of data in your hard disk. Bottom line is that some bad sector is affecting your entire data. So recovery here is probably hard than if you were to use multiple partitions for different category of data.

  • You install your favourite linux distribution by partitioning the hard disk:

    If you partition your hard disk say sda1 for boot, sda2 for root, sda3 for opt, sda4 for usr, sda5 for home and so on, now if some kind of crashing or bad sector problem occurs then there is a greater probability than the previous scenario that you might save/recover your other partitions. It is also useful in cases like, for example say that i have crashed my system (consider it an os problem) and system does not boot, i could reinstall my system without touching my home partition so, partition home is isolated and safe. Other benefits are as follows:

    1. less amount of time in file system check.
    2. freedom to choose different file systems.
    3. protection of file systems.
    4. ease in repairing file systems by pin pointing to the problematic file system.

And of course there are benefits of Logical Volume Management(LVM), it starts with a single volume group and subsequently creating multiple logical volumes to hold the necessary file systems. I personally don't use LVM, so for more you can visit Wikipedia and Gentoo

  • 3
    And one more point: you can manage much easy diskspace (if you use LVM of course). My personal set is to create dedicated: /, /usr, /var, /tmp, /home and if I use 3th party soft also /opt – Romeo Ninov Feb 8 '15 at 9:39
  • @RomeoNinov, added. – skush Feb 8 '15 at 10:02
  • 1
    Note that this is true for all Unix, BSD and Unix-like systems. – Rob Feb 8 '15 at 13:31
  • 2
    I don't see how splitting up the partitions in any way affects recovery. A typical FS doesn't allow random failures to completely junk the entire partition. Perhaps you can't boot your OS but you can always boot up from USB/CD/whatever and access your data. – edA-qa mort-ora-y Feb 8 '15 at 14:11
  • @edA-qamort-ora-y, Well a typical FS failure might make the system inaccessible say a soft bad sector in MBR. With multiple partition you can isolate that partition which contains soft bad sector, reinstall the OS w/o affecting user files, so obviously it makes the recovery of system "easy" and by recovery I mean to make the system functional. – skush Feb 9 '15 at 7:29
3

Lack of partitions is a common cause for needing recovery in the first place.

A partition table is the most common / standard way to declare that the disk is in use (and thanks to various partition types, it usually also declares what exactly each partition is used for).

An unpartitioned disk looks like an unused disk to many programs; installers select them for installing; partitioners create partition tables on them; it's easy to get damage in your filesystem metadata or LUKS header if you don't create a partition for them yourself.

If you know exactly what you're doing and have full control over your environment, you might not need partitions. I'd still recommend you use them, though.

2

This was true once - once upon a time drives were smaller (and slower), as were tapes. If you have a large raid group, and suffer a (compound) fault - all data on that raid group must be recovered.

As sizes increase, so too do the numbers of tapes required.

So a large filesystem, where you're doing a full restore might mean recovering everything and doing so from a sequence of tapes where you recall full backups and subsequent incrementals. On a large file server, this can be very time consuming.

Similarly - the backup cycle could end up taking a very long time - there was a very real danger that you'd not be able to complete your 'daily' backup schedule every day.

So instead what you would do - create separate filesystems on separate physical devices, and back them up independently. You could then stagger you backup or stream to different tape devices. If a failure occured, you'd replace and restore just that segment, and be done.

These reasons still apply to an extent, but drives and tapes are bigger and faster. (And plenty of people back up direct to disk anyway). Automated rebuilds are smoother too.

So now, they key reasons to partition are:

  • control over space usage. You don't want a user to blow away 'root' because they downloaded too much junk into 'home'.
  • Segregating 'things you need to back up' from 'things you don't'. If your automated rebuild process is smooth enough, you should be able to rebuild faster than you recover, and you then just add the transient data (database files, user data etc.).
  • Segregation of disk config. You probably don't need high performance or high resilience disk throughout. You may then choose different disk tech or RAID types.
  • disk layer backups - you can snap or clone, but usually you can only do this at a per LUN level. This tech enables some quite cool recovery/roll back/forward options, but it's necessary to segregate the storage you're doing with. (You don't want to wipe your home drives each time you roll back an Oracle DB)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.