I know this might seem a strange question and I know I should buy a good UPS but I already had had two of them and none of them did a good job. I'm living in a house where many power outages occur (please, don't ask me why...) so data loss risk is very high. I bought a new SSD but I'm planning to keep my old HDDs, so I thought about this configuration:
/ on SSD (ext4 of course)
/var on HDD
/tmp on HDD
/swap on HDD (swappiness set to 1 since I have 4 GB of RAM)
scheduler = deadline or noop (can you point me a good way to do this permanently?)
journaling = enabled (due to the power losses I can't just disable it but is it possibile to store the journal on another HDD? If yes, how?)
discard and noatime in fstab
What do you think about that?
The SSD I bought is a Samsung 120 GB 840 series and my mainboard supports SATA2. Is it really needed to put var, tmp and cache on another HDD? What if I just install the whole system on my SSD, how many time do you think it will last?
Thank you so much and sorry for the odd question.
sorry, have totally overseen your comment. sometimes I am blind.
I don't know what you are using in your home-directory. But I would then put any folder resp. Partition on to your ssd and then put /home onto your normal hard-disk-partitions.
for example it is good when /tmp-folder has a size not smaller than 4.7 GB, because then burning dvds has no trouble with sizes like 4.3 or 4.7 GB - discs.
swap-partition too on your ssd.
I myself have all partitions on 120 GB - ssd and I don't use loads of graphics, games or music files in my home-folder - so there is still space for about 30 Gibi left. But 120 GB would be too small if you plan to install windows too.
you can use gparted-program - it is given in ubuntu-live-CD.
easier for you.
in gparted you need first to create a partition-table - in case
you later need to rescue/recover your hard-disk (a rescue can fail when partition-table
is not created before that)
(if you want to be proof against hack-attacks you can leave away partition-table, but
then later you can have trouble if rescue/recover is necessary).
so you have now a partition-table created with gparted (look there in menu...)
you need (allowed are only 4 partitions - except: you create logical partitions,
but here you dont need logical partitions (harddisk is too small))
1 swap-partition (=size of 2xRAM file-system:swap) 8 Gibi (8x1024 MB)
1 /tmp-partition (file-system: ext4) about 10 Gibi is sufficient ( 10x1024 MB)
1 /-partition (for root - file-system: ext4) (30 Gibi is enough)
1 /home-partition (file-system:ext4) (rest for home is enough)
Keep your partitions as they are, and use the SSD to cache them. See How do I install and use flashcache/bcache to cache HDD to SSD?
My current situation is:
Now I want to install an 80GB SSD and move Ubuntu to it. AFAIK I need to:
How do I do the second? And what do I need to do about Grub?
You want to copy the FILES, not the whole partition ( including its free space ), so you don't need to resize the partition first. Boot from the livecd and mount both the HD and SSD ( after formatting a partition on the SSD of course ), then copy all of the files over:
sudo cp -ax /media/hd /media/ssd
Use the correct names for the hd and ssd mount points of course. Then you just need to edit the /etc/fstab on the ssd to point to the new fs UUID ( you can look it up with blkid ). Finally you need to install grub on the ssd:
for f in sys dev proc ; do mount --bind /$f /media/ssd/$f ; done
Of course, use the correct device for /dev/ssd. The whole disk, not a partition number. Finally reboot and make sure your bios is set to boot from the SSD.
I was able to do this migration successfully thanks to @psusi's instructions, however I observed one "gotcha."
After installing Grub on the new SSD, it still wouldn't boot - it was looking for the ramdisk image using the UUID of my old OS drive, which I had removed. Using the --recheck option fixed this:
$ grub-install --recheck /dev/ssd
This encourages grub to re-scan the BIOS, identify the new drive, and presumably use its UUID when passing the "root=" parameter to the kernel.
Considering your HDD is /dev/sda and SSD is /dev/sdb and partitions are properly sized, you may use simple cp:
cp /dev/sdaX /dev/sdbY
Where X and Y are corresponding partition numbers.
However this method will copy 80GB of data and all sectors on your SSD will be marked as "occupied" initially.