On 09/08/14 03:08 AM, B. M. wrote:
Why not just use the capabilities of btrfs and avoid the hourly backup and RAID1 entirely then? A nightly backup along with perhaps some longer-term archiving backups would use fewer resources during periods when you are actually using your computer.Le 9 août 2014 à 06:04, Gary Dale <garydale@torfree.net> a écrit :On 08/08/14 06:14 AM, B. M. wrote:Hi all, While I'm waiting for the components of my new machine (testing/jessie) I'm thinking about the optimal partitioning scheme which should last for the next 10 years :-) The system looks like: Haswell 3.4 GHz 8 GB RAM (later upgradeable up to 32 GB) 250 GB SSD 2 TB HDD What do you think about the following: === SSD: === /boot unencrypted, 300 MB / ext4, encrypted, 25-30 GB /home ext4, encrypted, keyfile, 220-225 GB User data for two users === HDD (in this order for performance reasons): === /var HDD, ext4, encrypted, keyfile, 25 GB It's so large because I want to add a directory /var/src below /var to compile a kernel on the HDD if necessary /databases HDD, ext4, encrypted, keyfile, barrier=0, 10 GB Used for the db's of digikam (1 user), akonadi and amarok (2 users each) swap HDD, swapfs, encrypted, 5 GB (not hibernation) /video HDD, btrfs, 560 GB Subvolumes: /video/editing /video/series => for video editing or series, no backup, not encrypted /data HDD, btrfs, encrypted, keyfile, RAID1 (2 x 700 GB). With subvolumes for digikam archive, movie archive and music What do you think (sizes, file systems, number of partitions, ...)? Is it still a good idea to put /var on an HDD, not a SSD? Video editing is currently not required, it's more like an option for the future (1y or so) and might require a second HDD (source and target drive for rendering to increase r/w performance). To keep it simple and usable I'll use keyfiles for all partitions except /. Thanks for your inputs and all the best.Everyone has their own preferences on this but I actually have several machines with a very similar setup. The major difference is that I use RAID rather than single mechanical disks. My preference is to use the SSD for /, with an area left for for the GUID boot. I partition the larger drive/array as a single partition and mount it as /home. I've never really seen a need to engage in the multiple partitions that some people seem to like. You're never likely to fill the / partition and if you fill the /home with some of your data, then expand the RAID array. Some people like LVM but frankly with the good tools Linux has for resizing partitions, it's rarely needed. I don't like the idea of using two partitions on a single HD for RAID, which seems to be your plan. I'd opt instead to go immediately to RAID 5 with 3 drives. 1T drives are quite cheap these days so the cost difference isn't significant over a single 2T. If you want to save money, a 60G SSD is all you really need for / anyway. I'm also not concerned about wear on an SSD. I've been using them for years and have yet to have one fail. It will happen at some point, but I trust them more than I trust an HD. However since your SSD isn't in a RAID array, I wouldn't trust it with anything that can't be recovered with a fresh Linux install.Well, actually my idea is to have the a normal, hourly backup on an external /ext4-formatted drive for home and /etc. btrfs for /data in the RAID1 setup is to protect against bit rot (photo & movie archive which should be save for decades...); ontop of that I plan an additional partition for /data on the external drive as well to protect against hardware failure of the internal drive, so the only threat I currently see is a problem of the btrfs fs hurting both the internal RAID1 and the external btrfs. But if I use ext4 for the external /data backup I'm not easily protected against bit rot.
To preserve your archive, I'd advise PAR2 redundancy files to fix any problems that may crop up. So long as your HD copies are good, you don't need to go to the PAR2 files, but should one develop a problem, you can fix it with the PAR2 files. Having 5% to 10% redundancy is a lot cheaper than RAID1.
You can automate the PAR2 creation by checking for new files and creating PAR2s for them.