4

I am interning at a software company and I have hit somewhat of a brick wall. Here is the deal:

The Problem: We have some boxes around here that were incorrectly partitioned for 2 x 500 GB drives. The actual drives are 2 x 1 TB drives. These are essentially machines with only half of their available disk space being used. I am tasked with writing a script to re-partition these drives.

Solution Thus Far: I have a script that disables all process and reboots, and then another script that fixes the partitions. The problem is that there is a loss of data.

What I'm Looking For: I need a solution that does this but saves all the data. My first though would be to just grow the partitions to their appropriate size, but I'm not sure if that is possible. The other solution is to copy all data onto Disk2, partition Disk1, move data back to Disk1, and finally partition Disk2. The problem is that I am pretty new to Linux and I don't really know how to do it. I have access to the fdisk utility and the parted utility.

They are all of type ext3.

EDIT: 11/3/11

Okay. So I have approximately 1GB of unused, unallocated space on both disks. I want to do as follows:

  • Create a new extended partition on SDB of size 1GB, called sdb99 for reference here
  • Copy sda5 sda6 sda7 to the new SDB partition sdb99
    • Can I just copy "/" from each of these to some folder in this new partition?
    • Do I need to put a filesystem on this new partition to copy any files on there?
    • If I just copy "/", will that preserve the whole directory structure?
    • Is it a simple task to move files between disks like this?
  • Delete sda5 sda6 sda7 and then re-create them with twice size
    • Do I actually need to delete these? I don't think that I can grow 3 contiguous partitions, and even if I could, the filesystem won't grow...right?
  • Copy back the data from sdb99 to the new sda5 sda6 sda7 partitions
    • This should be as simple as moving the contents of those directories containing all the "/"'s back, right?
  • Copy sdb5 sdb6 sdb7 into the new sda5 sda6 sda7 into separate folders.
    • There should be enough space because of the now doubled space available...I hope
  • Delete and re-partition SDB
  • Move the files from sdb5 sdb6 sdb7 back onto SDB

Does anyone see any glaring problems, have any pointers, warnings, suggestions, etc.?

Thanks everyone. Again, this needs to be scripted. Thanks.

EDIT 2 Here is the actual script...

#!/bin/bash

LOG=./repartition.log 

date > $LOG 2>&1

echo "Ok, let's get started." >> $LOG 2>&1

# Resize logical partitons
parted -s /dev/sda resize 4 45GB 2000GB >> $LOG 2>&1
parted -s /dev/sdb resize 4 90GB 2000GB >> $LOG 2>&1

# Create the temporary file systems on disk 2
mke2fs -j /dev/sdb8 >> $LOG 2>&1

# Copy sda6 sda7 sda8 to sdb8
cp -r -L -p /dev/sda6 /dev/sdb8/home/sda6 >> $LOG 2>&1
cp -r -L -p /dev/sda7 /dev/sdb8/home/sda7 >> $LOG 2>&1
cp -r -L -p /dev/sda8 /dev/sdb8/home/sda8 >> $LOG 2>&1

# Remove NBD partitions on disk 1
parted -s /dev/sda rm 8 >> $LOG 2>&1
parted -s /dev/sda rm 7 >> $LOG 2>&1
parted -s /dev/sda rm 6 >> $LOG 2>&1

# Create NBD partitons on disk 1
parted -s /dev/sda mkpart logical 70GB 713GB >> $LOG 2>&1
parted -s /dev/sda mkpart logical 713GB 1356GB >> $LOG 2>&1
parted -s /dev/sda mkpart logical 1356GB 2000GB >> $LOG 2>&1

# Create the file systems on disk 1
mke2fs -j /dev/sda6 >> $LOG 2>&1
mke2fs -j /dev/sda7 >> $LOG 2>&1
mke2fs -j /dev/sda8 >> $LOG 2>&1

# Copy sda6 sda7 sda8 back to sda
cp -r -L -p /dev/sdb8/home/sda6 /dev/sda6 >> $LOG 2>&1
cp -r -L -p /dev/sdb8/home/sda7 /dev/sda7 >> $LOG 2>&1
cp -r -L -p /dev/sdb8/home/sda8 /dev/sda8 >> $LOG 2>&1

# Copy sdb5 sdb6 sdb7 to sda6 sda7 sda8
cp -r -L -p /dev/sdb5 /dev/sda6/home/sdb5 >> $LOG 2>&1
cp -r -L -p /dev/sdb6 /dev/sda7/home/sdb6 >> $LOG 2>&1
cp -r -L -p /dev/sdb7 /dev/sda8/home/sdb7 >> $LOG 2>&1

# Remove NBD partitions on disk 2
parted -s /dev/sdb rm 8 >> $LOG 2>&1
parted -s /dev/sdb rm 7 >> $LOG 2>&1
parted -s /dev/sdb rm 6 >> $LOG 2>&1
parted -s /dev/sdb rm 5 >> $LOG 2>&1

# Create NBD partitons on disk 2
parted -s /dev/sdb mkpart logical 90GB 726GB >> $LOG 2>&1
parted -s /dev/sdb mkpart logical 726GB 1362GB >> $LOG 2>&1
parted -s /dev/sdb mkpart logical 1362GB 2000GB >> $LOG 2>&1

# Create the file systems on disk 2
mke2fs -j /dev/sdb5 >> $LOG 2>&1
mke2fs -j /dev/sdb6 >> $LOG 2>&1
mke2fs -j /dev/sdb7 >> $LOG 2>&1

# Copy sdb5 sdb6 sdb7 back to sdb
cp -r -L -p /dev/sda8/home/sdb7 /dev/sdb7 >> $LOG 2>&1
cp -r -L -p /dev/sda7/home/sdb6 /dev/sdb6 >> $LOG 2>&1
cp -r -L -p /dev/sda6/home/sdb5 /dev/sdb5 >> $LOG 2>&1


rm /etc/init.d/fix_partitions >> $LOG 2>&1
rm /etc/init.d/local/99fix_partitions >> $LOG 2>&1
mv /etc/init.d/local/gca_init.off /etc/init.d/local/99gca_init >> $LOG 2>&1

echo "All set.  Please reboot.  Have a nice day." >> $LOG 2>&1

date >> $LOG 2>&1
reboot >> $LOG 2>&1
grav3mind
  • 41
  • 2

2 Answers2

6

Why does it have to be scripted? I'd reboot with a boot disc like RIP (rescue is possible) Linux in X, run gparted (a graphical utility), and resize the partitions from there. Gparted has the ability to resize partitions without damage (at least I've not had a problem with NTFS; haven't had to do it much at all with Linux partitions)

BUT

YOU SHOULD HAVE A BACKUP OF THE DATA

It's just plain silly if this is important data to not have backups and play with the partitions. Or downright stupid, depending on how important the data is.

Bart Silverstrim
  • 31,172
  • 9
  • 67
  • 87
  • If he's only moving the partition's end offset, this shouldn't even need to do anything potentially destructive with the data. It should take literally thirty seconds once the process starts. (Obviously backups are a must either way -- they're a must whether you're playing with partition tables or not, but now is a good time to verify that they're current and working.) – jgoldschrafe Oct 27 '11 at 19:37
  • +1 for having a backup of the data before playing around with the partitioning or resizing filesystems. – Evan Anderson Oct 27 '11 at 19:37
  • @jgoldschrafe: They key word there being "shouldn't". – Evan Anderson Oct 27 '11 at 19:38
  • The problem with doing it with a boot disk is that there are literally dozens of systems distributed around different offices and locations. I cannot back the data up remotely, and I actually don't even know what the data is. For all I know the data is just our appliance and an OS, but all the disk space isn't partitioned. I have been tasked with scripting a simple solution involving no backup, just properly partitioning all these systems. @kvisle - I don't know what LVM is. I am somewhat of a Linux rookie. – grav3mind Oct 27 '11 at 20:20
  • Please post the output of `fdisk -l; pvs && vgs && lvs`. – Nils Oct 27 '11 at 20:37
  • @grav3mind: You really might want to rethink what you're doing if you're being tasked with playing with partition tables on an office server and you're a self-described linux rookie... – Bart Silverstrim Oct 27 '11 at 23:52
  • Primarily because this is an office server and there's *no backups* in place? – Bart Silverstrim Oct 27 '11 at 23:53
  • And why would you script something like this? Changing partitioning around isn't something that's typically scripted unless you're part of a team working on imaging a number of workstations or servers for rollout. What you're doing is playing with fire, experimenting on a production server like this without a backup solution in place. – Bart Silverstrim Oct 27 '11 at 23:54
  • Thank you everyone. I agree, but what am I supposed to do? I am an intern and I'm not going to tell them how to run their company. I think that if it is that vital then they would not be having me do it, but someone more experienced. They know what my capabilities are, they know I'm a Linux rookie, and I've been here for 5 months so they know what I can and can't do, and they assigned this to me anyway. That leads me to believe that there has gotta be a simple way of doing things. Anyway, I'll post what my method is, and then hopefully you guys can give me some pointers... – grav3mind Nov 03 '11 at 17:59
  • First, if you're right that this isn't a mission critical system or they wouldn't have put you on it, the first thing to have is a full system image or backup in place so that if you had to recover it, you can. – Bart Silverstrim Nov 03 '11 at 23:14
  • Second, it would be silly of them to beat you down for saying you don't know how to do something if you're working with a team. If they know better, they can show you or help you. Or at a minimum, work with you so you can learn what to do. – Bart Silverstrim Nov 03 '11 at 23:15
  • Third, don't feel bad for having to say "I don't know." It takes bigger balls to know your limitations than to pretend to bluster your way through it. – Bart Silverstrim Nov 03 '11 at 23:16
  • Fourth, if they knew how to do it, they'd either do it themselves or they're testing you. We're in no position to know either way. So make sure you have the system backed up and restorable, then assemble your plan of action, and have them review it or bring it here to see if someone can take a few glances at it for you. As long as the backup and recovery plan is good, you shouldn't fear working on it. Good luck! – Bart Silverstrim Nov 03 '11 at 23:18
0

IIS uses a different account than the one that is used for mapping. It's either IUSR or IWAM account on the SERVER A. Which is probably seen as GUEST by the SERVER B. The easiest and the most accurate way from technical and security perspective will be the following:

  1. Configure Auditing on the share that provisioned on SERVER B to monitor which user is trying to access the share and write files to it.
  2. Create / Alter user accounts and/or permissions on the share which is located on SERVER B.
Vick Vega
  • 2,398
  • 16
  • 22