Error connecting a USB drive for backup

Error connecting a USB and using it as default backup location

My YunoHost server

Hardware: Raspberry Pi 3B at home
YunoHost version: 3.7.1.3
I have access to my server : Through SSH and through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

Hi dear Yunohosters!

I’m using Yunohost on a Raspberry Pi 3B and I heard that an SD card is quite prone to failure (Expanding diskspace for apps after installation - through USB or external Harddisk ). Therefore I wanted to create (if possible automatic/periodic) backups of the instance not locally on the SD card, because if it fails you also lose backups. Besides, storing local backups eventually cuts the space on the SD card that I have for documents etcetera in half. So instead, I want to connect a USB thumb drive to the RPi which has the same amount of storage as the SD card, and create my backups on there. That is what I would like to achieve.

Issues

Since the documentation on backing up does not state much about doing backups on an external disk. I had to rely on some other sources as well. I had two issues here:

  1. Yunohost does not automount a disk. This made me have to dive deep into mounting and fstab through the command line for a few hours. It would be great for usability if Yunohost supported automount. (or a GUI guided automount if normal automount it is not available for security reasons)
  2. When I finally created an fstab line and was able to automount, and after creating a symlink to the new disk, I tried to make a ‘local’ backup through the webadmin. It failed with the following message:
Your archive directory '/home/yunohost.backup/archives' is a broken symlink. Maybe you forgot to re/mount or plug in the storage medium it points to.

My guesses

My guess is that for 2. the issue lies with user permissions, because I had two apparent irregularities concerning those in the process:

  • I was unable to use sudo chown admin:users /media/ynh_backup as the command gave the error:
chown: changing ownership of '/media/ynh_backup': Operation not permitted

I even tried in root, without success.

  • When following the instructions in the backup documentation to create a symlink a sudo was apparently needed in my case for the command:
sudo ln -s $PATH_TO_DRIVE/yunohost_backup_archives /home/yunohost.backup/archives

Main question

I would really like to have issue 2. solved so that I can make backups on the external USB thumb drive. And I hope that somebody could help me :slight_smile: How can I solve the symlink for backups to start working on the external thumb drive?

Thanks a bunch already! :smiley:

Details

I documented my workflow in more detail hereunder:

Mount a usb disk and use as default backup location

ssh into the yunohost: ssh admin@ihost.mydomain.nl

FIRST MOUNT THE DISK AND MAKE SURE THAT IT WILL AUTOMOUNT AFTER ANY REBOOT OR REINSERTION

Put a disk in a usb port of the server. Check where the disk is:
sudo fdisk -l or lsblk

From the command line create a mount point:

mkdir /media/ynh_backup/

https://askubuntu.com/questions/771473/mount-cant-find-device-in-etc-fstab


Then mount the disk at the mount point:

mount /dev/sda /media/ynh_backup

Then configure the fstab file (so that the disk is automounted at startup), see the next commands.
https://www.howtogeek.com/444814/how-to-write-an-fstab-file-on-linux/


Get information about the mounted disk:
cat /etc/mtab | grep sda

Get the UUID of the mounted disk:
sudo blkid | grep sd


[
/dev/sda /media/ynh_backup vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

/dev/sda: LABEL="Ynh_backup" UUID="4A3C-1AD6" TYPE="vfat"
]

Edit the fstab file with the retrieved info:
sudo nano /etc/fstab

Add for example: 
#Ynh_backup drive
UUID=4A3C-1AD6  /media/ynh_backup       vfat    rw,relatime     0       0

Save the file.

Test the automount without rebooting the server. First unmount the disk: 
sudo umount /dev/sda

Check if devices are present but not mounted:
lsblk | grep sd

Use the mount command with the -a (all) option to remount all the file systems in fstab:
sudo mount -a

And check again if it is mounted now:
lsblk | grep sd

Now you have to change the ownership of the mountpoint (otherwise only root user can use it?):
sudo chown admin:users /media/ynh_backup

Somehow this last command for changing ownership doesn’t work. I get the error: “chown: changing ownership of '/media/ynh_backup': Operation not permitted” Perhaps it is not needed on Yunohost?

THEN GET THE YUNOHOST BACKUPS TO THE NEW DISK PATH

Set the path to the drive mount point in a temporary variable:
PATH_TO_DRIVE="/media/my_external_drive" # For instance, depends of where you mounted your drive

Move existing backups there (will fail if you haven’t made any backups yet):
mv /home/yunohost.backup/archives $PATH_TO_DRIVE/yunohost_backup_archives

Add symlink to the new location for backups to be stored (apparently needs sudo to work):
sudo ln -s $PATH_TO_DRIVE/yunohost_backup_archives /home/yunohost.backup/archives

When then making a local backup from the Yunohost GUI it fails with the following error:
“Your archive directory '/home/yunohost.backup/archives' is a broken symlink. Maybe you forgot to re/mount or plug in the storage medium it points to.”

Naively my guess is that you did not create the folder yunohost_backup_archive inside $PATH_TO_DRIVE …?

What if you mkdir $PATH_TO_DRIVE/yunohost_backup_archives ?

Hi Aleks,
Thanks a lot, that was the case! I will create a pull request to change the documentation to add (sudo)

mkdir $PATH_TO_DRIVE/yunohost_backup_archives 

before the mv step.
Cheers!

@Aleks Do you know if automount is not supported as a deliberate choice or not, by any chance?

It’s probably not a deliberate choice, it’s probably just that we have thousands of things to do and didn’t take time to work on this in particular, but feel free to come and contribute :confused:

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.