BadT18 said:
Hey Guys
I am now building a Arch Backend Home Server and i have a couple of question before i start.
Here is a list of what i need the server to do
Myth-Backend
Torrent Flux, Webmin, MythWeb
File Share (Samba/NFS)
Run a XP Virtual Machine (Most liky kvm)
1. To set up myth-backend does X need to be installed. should i have a desktop installed or can it all be done at command line.
Yes you need X but you don't need a graphic card. It's possible to install vnc, run a virtual framebuffer, connect to it remotely from another machine via a vnc viewer and run the myth setup program that way.
Quote
2. I'm gonna have 4x 1tb hard drives (raid 5) with lvm but still have 1 big file for it eg /media. (is this correct cause its lvm i can add another hard drive to the raid at anytime)
No. That's a lousy Windows view of the world in hard disc land. You're far better off to:
1. Make the raid5 array with mdadm.
2. Create a volume group from the resultant array.
3. Create smaller (no where near full size of the array), logical volumes for separate types of files.
If you just make 1 huge disk the size of the array you may as well not use lvm and just format the full 4 TB as one filesystem and mount it without lvm.
lvm gives you flexibility. The most obvious example that I use is this:
If you have one big /media (4tb), and your Live/Recorded TV goes into there, you won't monitor how much space it's using up. Myth will tell you you have zillions of hours recording time left, but eventually the 4tb will start to fill, you'll add a heap of HD movies to your movies directory, a heap of downloaded tv in there, music, photo's etc etc... Then one day you'll realise you have 1TB of recorded TV that has to be cleanup up but you'll no longer have the space to move it anywhere or even transcode it to a smaller size. It's far better instead to create logical volume of 300GB in size for recorded TV. If it starts filling you can do something about it before it fills the array, it also keeps the family (or yourself) in check as you're forced to do something about it sooner.
There are many other reasons. I always suggest this sort of layout (from my machine on a raid 5 array):
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 10M 288K 9.8M 3% /dev
/dev/sda2 ext3 14G 11G 2.7G 80% /
none tmpfs 1008M 0 1008M 0% /dev/shm
/dev/mapper/raidvg-lv_home
ext4 50G 32G 15G 69% /home
/dev/mapper/raidvg-lv_audio
ext4 60G 47G 9.8G 83% /home/rick/Documents/audio
/dev/mapper/raidvg-lv_video
xfs 3.0T 2.5T 536G 83% /home/rick/Documents/video
/dev/mapper/raidvg-lv_tv
xfs 300G 81G 220G 27% /home/rick/Documents/video/RecordedTV
/dev/mapper/dlvg-lv_downloads
ext4 296G 162G 119G 58% /home/rick/Documents/downloads
/dev/mapper/raidvg-lv_images
xfs 25G 16G 9.5G 63% /home/rick/Documents/images
/dev/mapper/raidvg-lv_videoedit
xfs 600G 552G 49G 92% /home/rick/Documents/video/Edited
As you can see each "area" is it's own logical volume. This allows me to:
1. Have different filesystems for the various types of files. xfs is useful for large files (like video), ext4 is good for smaller files, not doing this will consume far more disk space than it should.
2. xfs filesystems are checked much faster than ext4 ones. If you have the whole space as one big drive and the system wants to do a 30 day "fsck" check it'll be an hour before the system can be used. So it makes sense to have the larger logical volumes (video), as xfs.
3. xfs can be defragmented as well which can speed performance for tv/video.
4. Having the logical volumes separated and at the size they need to be gives you flexibility. If for some reason you need more space for music, then you allocate it to music.
5. If someone gives you a pile of video files (1tb for instance), and you haven't allocated all the space, then you can create a temporary logical volume called "to sort", dump it all in there and then you can go through it and copy things into your real "video" volume that you want to keep. When you're done delete the logical volume and the space becomes free to allocate when you need it.
6. Doing it the above way makes you manage your storage. The idea is to leave as much space empty as possible, as you allocate it where it's needed you'll see when it's time to start thinking about getting more space. Rather than the windows way of panicing when all 4TB is full, no sata ports are left, and you can't fathom how to move 4TB of data from 4x1tb disks to 4x2tb disks.
7. The above keeps your options open. i.e. If you did have 1 sata port left you could plug in a 2TB drive, add it to the volume group, and lvmove one logical partition from the array to the new disk. This is done at block level so there's no file copying, lvm takes care of everything.
In short, it allows you to juggle things enough to be able to upgrade the size of the array onto new disks without any file copying like you'd have to do in Windows.
8. Backup. It's a damn site easier to back up important content when it's logically separated by defined boundaries.
Good storage management happens well before you format the first disk. Design it well and it will serve you well. Slap it all into one big "virtual" 4tb disk and you'll live to regret it, over and over and over ;)
Quote
3. I also gonna have 1 500gb hhd and 1TB hhd for the rest of the server. i am wanting to have 30gb from the 500gb hhd as root / but have this 30gb raid 1 on the 1TB hhd so i dont have to rebuild the server if the 500gb hard goes. (is this possible? is it just lvm???)
If you want. It can be done with pure lvm of the probably better way would be with a combination of lvm on top of md, and for a home server, is just overkill in my opinion. It'll add a lot to the overhead of managing it. I've thought about doing this myself but I find that if each time I make a change to my server I take a clonezilla image, then I'm fully covered anyway (and once it's built it hardly ever changes). Mirroring / is what we do on corporate servers. For home it's not really necessary. Besides. If you have /home on the raid volume (where it should be), then 98% of configuration data is safe, even if you have to re-install the OS and packages. if you make sure /etc is backup up then that's 100% covered. The OS files themselves can be put back easily. It's the config you don't want to lose and all that lives in /etc and /home.
Mirroring / means your initrd has to be lvm and/or md aware and it can make kernel upgrades difficult if anything goes wrong and you can't boot from a live cd and mount your root filesystems.
Quote
4. on the 1TB hhd i want to have (30gb for raid 1 of root) then the rest mount /software and as /downloads (is this possible?) i want the whole 1tb spreader across 2 mount points. or do i have to set a size on both so 500gb on each
lvm will let you add a partition + an entire drive into one "virtual drive", called a volume group which you an then create logical volumes of any size on. They can span less that one disk or all of both disks. Whatever you want. But again, it's better to not allocate ALL the space up front. I have 12TB (10TB usable) in my machine but currently only 4TB is allocated:
--- Volume group ---
VG Name raidvg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 10
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 1
Act PV 1
VG Size 9.10 TiB
PE Size 4.00 MiB
Total PE 2384657
Alloc PE / Size 1048320 / 4.00 TiB
Free PE / Size 1336337 / 5.10 TiB
I'll use that space when I need to ;) I also have a single 1TB sata in use as a boot drive and there is something else that you haven't yet factored in. What happens when you need to do package upgrades to upgrade your OS? Or if you need something new? The design most of us are using caters for a second partition to "copy" your existing root (/) to. You can then boot from it, upgrade it, test it, confirm it works etc etc. Assuming it can take days to do that testing you leave the default grub boot to boot the original fully functioning OS. When you're happy the upgrade is complete and fully tested then you switch grub to boot from the upgraded copy, freeing the old one for the next upgrade cycle. You can't do any of that easily with lvm.
So my 1tb drive is partitioned as:
sda1 - /boot (or more accurately, grub files only)
sda2 - 2gb swap
sda3 - 15gb (OS primary)
sda4 - Extended partition (rest of the drive)
sda5 - 15gb (OS secondary, for upgrades)
sda6 - remainder of drive (/downloads). Not raided, but I don't care if I lose anything in there.
To backup, I simply image sda3 or sda4 (whichever is the active partition). In your case you can merge sda6 with sdb (a second 1TB drive), with lvm to have it all usable. Note though that if you lose either of sda or sdb the contents of the logical volumes on BOTH those disks will be gone, so nothing is safe in that scenario. So your /software and /downloads would cease to exist. Don't put anything in there that you want to keep :)
This also brings up another point.. Bet you didn't realise these questions were so big? Raid5 IS NOT A REPLACEMENT for backups. I've seen numerous raid array's die completely. It only protects you from failure from 1 disk and you'd better make sure you get alerted if 1 ever fails as the second one may not be far behind. If you don't back up important files consider them as just as unsafe on a raid 5 array as they are on a single drive.
Quote
5. i have 4 onboard sata ports and 1 via 6421 sata raid card as i dont wanna hardware raid is t possiable to boot from the raid card in linux?? its only sata1 speeds so i dont wanna put any of my raid drives on it
what am i best to do about this???
Depends on the card and your bios. Only way to find out is to try it. Personally I'd go and buy a cheapy sataII PCI card and use internal ports for your boot disk and use the rest of the internals+PCI ports for the array. The good thing about software raid is you can move all the disks to a new motherboard with 8 sata ports later on and everything will just work (just did this myself, it's very cool). Then you'd have another 4 ports to build a 2tb disk based 8tb array you can move the 4tb off onto, then replace those 4tb with another 8tb, create an array on it too, then combine both 8tb arrays with lvm to grow the existing lvms across 2 arrays...(all directories/moutpoints remain unchanged even though you've quadrupled your storage! Ultimate Flexibility without a bunch of unnecessary file copies, creation/deletion of things, no juggling, just more space :)
Quote
No need. I just explained the partitioning scheme that you were missing in this one ;)
Glad there's no more questions. My keyboard is on fire!!
Cheers,
Arkay.
Sign In »
Register Now!
Help
Post Sponsors