Results 1 to 10 of 10
Hi all,
I am working from a laptop where all my work is stored on a 80GB drive. I am now also an owner of an external 250GB USB hard ...
- 03-10-2011 #1Just Joined!
- Join Date
- Aug 2007
- Posts
- 24
Good backup utility / script / app, got an external FAT32 drive
Hi all,
I am working from a laptop where all my work is stored on a 80GB drive. I am now also an owner of an external 250GB USB hard drive, formatted with FAT32. I want to keep it FAT32, so that I can offer some of my files to people that run Mac OS or Windows and I don't want to have them install ext3 for windows and what not.
I am in need of a strategy which will allow me to keep a mirror of my laptop drive on my new external drive, i.e. no history / versioning required. However, I do care about file permissions. The files don't have to be stored as-is, they can be stored within a large (80GB?) tar file, that is fine - it would be easier for me to coerce people to open a .tar file than to install an ext3 driver for their OS, I suppose. I don't think I can keep file permissions otherwise, can I?
I have previously used a self-written sh script that used rsync to keep an up-to-date copy of my laptop filesystem on a USB flash drive, but in that case I had the flash drive formatted with ext3, so no problem with file permissions there. This time, it's trickier...
Any advice, please?
- 03-10-2011 #2Just Joined!
- Join Date
- May 2006
- Location
- Silver Spring, MD
- Posts
- 32
AMN,
Bumping this thread so that I can follow it. It's an interesting problem you have. I've done what you are trying to do but I've never tried to keep permissions in place. If you tar them, and then untar them, the user that untars will be the owner. Personally, I would say forget the Windows folks, cut an 80GB partition out of your external, and then use DD for a bit by bit copy.
dd if=/dev/internal of=/mnt/external
And based on your post, you seem competent and probably already know this, but it's the only way I can see of keeping things as is. Anyway, hopefully someone a lot smarter than me will answer your call and we'll both learn something.
Sorry I couldn't help,
KaBar's Edge
- 03-10-2011 #3
A Linux partition is going to be your best bet from a file system permission and reliability point of view. Why not partition the drive - keep a FAT32 partition for sharing stuff with your Windows only friends, and a Linux partition (ext2, ext3 or ext4) and use rsync to keep an up to date copy of your Laptop drive.
Just rsync or transfer stuff to the FAT32 partition you want to share ... it also means they won't screw your backup data
- 03-11-2011 #4Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,970
Linux does pretty well with NTFS file systems now. In any case, DO NOT TRUST FAT32 for any system backups. It is way too unreliable, and often unrecoverable when corrupted. So, if you need Windows users (and possibly Mac users) to access your data by plugging in the drive to their systems, I'd advice using NTFS - the Linux ntfs-3g driver is very stable and quite efficient. It will also be much more space-efficient on that 250GB drive.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 03-12-2011 #5Just Joined!
- Join Date
- Aug 2007
- Posts
- 24
will use ext3
Yeah, I have decided to format all or most of it with ext3. ext4 is too new for me to trust it with interoperability, ntfs clashes with my demands for native UNiX permission flags, and fat32 prevents me among other reasons to have files larger than 4GB, including possible .tar backups. I am thinking perhaps to have a smaller fat32 partition on it, say 4GB, just in case and so I can keep an offline copy of ext3 driver installer for both Mac and Windows.
That's the best strategy I can think of now. I will also be able to use my old rsync-based backup scripts, and no need to mess with tar. I have nothing against it, but it takes a while to browse .tar archives and if I have ext3 I can simply use the filesystem itself instead of the tar "filesystem".
Thanks for all the help!
- 03-18-2011 #6Just Joined!
- Join Date
- Aug 2007
- Posts
- 24
Just found out that apparently the device uses 4kB as physical block size. GParted, the application I would use to format the disk, does not understand it (in its current version), so I am stuck with what I have, afraid to brick the drive. I am not really an expert on this, even though long ago I used to grok this stuff just fine... What are my options? Will some fdisk/cfdisk/parted wizardry help here? Maybe I can just wipe out the partition table, and the limitation will go away, and I can start GParted again and it will do its job?
- 03-18-2011 #7Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,970
What distribution, version, and kernel are you using? Newer kernels support 4k block sizes just fine.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 03-19-2011 #8Just Joined!
- Join Date
- Aug 2007
- Posts
- 24
Linux $hostname 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 09:00:03 UTC 2010 i686 GNU/Linux
It's not the kernel that doesn't support 4K blocks, it's GParted 0.5.1 (libparted 2.2) application (and probably its backend - parted) that gives me the warning and aborts so I cannot even begin formatting the drive.
- 03-19-2011 #9Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,970
Well, gparted is up to 6.0, so maybe the newer version has fixed this issue? I'm running a 2.6.32 kernel also (RHEL/SL6), and the version of gparted in the epel repository is 6.0. I haven't tried it since I don't generally use it, or haven't yet, but it might be worth updating and checking out.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 03-20-2011 #10Just Joined!
- Join Date
- Aug 2007
- Posts
- 24
I removed the GParted that came with Ubuntu, which lagged a couple of releases behind the current and then downloaded the sources for GParted 0.8.0 and have compiled and installed it successfully. It did complain a few times on physical block size of 4K in the console log and how not all parts of the application could work with it, but it did NOT abort like the previous version did. And so I have managed to install an ext3 volume spanning the entire disk on the device. My old backup script works fine with it

Thanks everyone for helping!


Reply With Quote