0

I want to setup a raspberry pi with two external hard drives for backup purposes.

Because of the raspberry pi power limitation, i guess i will have to use a usb hub to power them up.

My question is the following:

  • Is it possible to automount one drive on the usb hub to the filesystem and only periodically mount the other one for a limited time (something like 1 or 2 hours every weeks) ?
Nicolas G.
  • 11
  • 2
  • Sorry for being 'unclear' about my question, even if i don't trully understand why. Following your recommandation, i guess what i'm asking on the raspberry pi forum is : "Can you mount/unmout hard drives that are powered and connected to the raspberry pi via a usb hub ?". I will also ask on the Hardware recommandation forum about external hard drives that are powered with 3W or less in order to be able to power 2 of them without a usb hub as i would prefer not to use one. Regards, Nicolas – Nicolas G. Oct 20 '16 at 06:23
  • To answer, yes, you can mount/unmount drives.... that is built into linux. I feel like you might be confusing them being mounted with Windows "ejected" where the drives power down. The drives will likely spin while in use, mounted or not, and will consume power while connected. – Ian M Oct 20 '16 at 09:54
  • @IanM You can set the drives to spin down while mounted after a period of inactivity, see man hdparm. They then spin up again when required, although this may take a second or two. – goldilocks Oct 20 '16 at 12:18

2 Answers2

1

Can you mount/unmout hard drives that are powered and connected to the raspberry pi via a usb hub

Yes, whether they are connected and powered via a hub or not is irrelevant to everything explained here. All USB ports are parts of USB hubs -- just the build in ones aren't in a separate enclosure, etc. Daisy chaining hubs is possible, which is what you are actually doing when you attach an external one.

I'm dubious that you will be able to power two drives from a Pi, but then I have not tried and haven't researched what's available in terms of power requirements. As per my comments, there is not much point in looking for a high performance drive as that potential is going to be wasted; the Pi's ports are USB 2.0, with a max throughput of 35 MB/s. I have very seldom seen transfers get close to that. Also, this theoretical maximum is for all four ports combined, plus the ethernet jack if in use.

Power

So you might as well look for low power and cross your fingers. By default new models are capable of up to 1200 mA total from the USB, but except for the Pi 3, by default are limited to 600 mA. This may or may not be enough to power one drive; certainly it's common for people to complain here that it doesn't work until they add:

max_usb_current=1

To /boot/config.txt and reboot.

Mounting

Is it possible to automount one drive on the usb hub to the filesystem and only periodically mount the other one for a limited time?

Yes, you can do whatever you like along those lines. Personally I am not a fan of generic automounting (the kind that just mounts anything as soon as it is plugged in), and always disable it completely, so I am not sure what is possible there with regard to e.g., not mounting one drive in particular, although obviously you can unmount and remount something manually.

I believe automounting is usually a feature of desktop environments, so if you are running the Pi headless you will not need to worry about it. With regard to mounting a particular drive, we of course aren't really talking about drives, we're talking about partitions. A fairly simple way to arrange for a particular partition to be mounted is via udev rules and partition UUIDs. You'll find lots of examples of this online if you search for "linux udev uuid"; I actually don't do it exactly that way anymore and instead use a pair of rules like this:

KERNEL=="sd[a-z]" ACTION=="add" RUN+="mything.pl"
KERNEL=="sd[a-z][0-9]" ACTION=="add" RUN+="mything.pl"

Which is really a catchall for anything, i.e., it could be used to implement automounting. These are added in a file to /etc/udev/rules.d and should be applied after you run

sudo udevadm --reload-rules

Udevadm has various useful subcommands such as udevadm monitor, see man udevadm.

Anyway, with regard to UUIDs, to find them, use blkid. They are per partition, but I believe actually an aspect of the filesystem, and it is the UUID you want to use, not the PARTUUID. If the filesystem does not have one you may be able to assign it with tune2fs depending on the filesystem type.

Idle

mything.pl is really not important here (that's where I filter by UUID; note udev can get fairly complex in terms of information it hands to this process via environment variables; there's lots of reading about udev available online and it is easy to play with, although there may turn out to be a lot of confusing "gotchas").

What is worth noting is that for the drive I keep mounted 24/7 on a pi, I like to configure it to spin down while not actively in use. It then uses no power and should appear to be off (no sound, vibration, etc.). If the drive is capable of this and obeys standard protocols, this can be done with hdparm (you have to apt install hdparm first). For example:

hdparm -B 127 /dev/sda
hdparm -B 241 /dev/sda

Will set the drive (notice, that's a device node again, not a partition) to power down after 30 minutes of inactivity.

You do not have to unmount any filesystems to do this. What will then happen is as soon as the filesystems are accessed, the drive will be activeated by the OS again. This will cause a second or so delay.

FS Types

Although linux in theory has drivers for a wide range of filesystems, not good things are often said about the NTFS support, including the fact that it is processor intensive, so unless you have a reason to use that you probably should avoid it. To be fair, however, I'm not a windows user so avoid it anyway.

VFAT is probably the most portable, but depending on what the drives are to be used for the current linux native filesystem, ext4, is probably the best choice. If you do this, be sure to mount with:

mount -o noatime

This prevents recording of access times for files, which amount to unnecessary writes when reading. You can also set options like this via /etc/fstab.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
0

If i understand the question correctly - Keep the second drive unmounted.

Mount it by the backup script (at the beginning) and at the end of the script umount it.

If backup happens at night, you safely can unplug the disk or plug it back in during the day.

jet
  • 379
  • 2
  • 9