💾 Archived View for blog.schmidhuberj.de › 2022 › 02 › 27 › having-a-bad-day captured on 2024-05-26 at 14:45:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Posted on 2022-02-27
Somehow I am having a really bad day today. Everything seems to be going wrong and I really hope I can fix this.
At the start of the day, I wanted to backup my NextCloud instance, but I wanted to try something new instead of downloading everything, putting it on a USB-stick and throwing it in some corner. After some researching, it seemed NextCloudPi has some really good backup strategies using btrfs I wanted to try.
It seemed that I would just need to flash btrfs on a USB-drive, inserting this stick into the RasberryPi and configuring the backup in the configuration panel.
I therefore present you my journey written in four acts.
Flashing btrfs was no problem whatsoever. But I could not access the configuration panel because of some certificates. It seems that NextCloud itself and the control panel use different certificates, and this was problematic.
But not really, I just connected to the panel using the local IP-address. Problem solved.
Now that I have access to the control panel and have a USB-Stick ready, it should be easy going forward. But it was not. Checking on the automount section of the control panel, it expects both the already existing storage and the backup stick to have a label.
I am sure I gave the backup stick a label, and checking over ssh on the RasberryPi, the existing storage also has a label. So everything is ready to go. So I just inserted the USB-Stick and NextCloud seems to throw errors. Yay. I am just going to disconnect the USB-Stick and reboot the RasberryPi. And it actually worked, everything worked fine, my data is still there.
Looking into it a little bit closer it seems that the external hard drive of the RasberryPi is mounted on /media/myCloudDrive (where myCloudDrive is the label of the file system), but there is also a /media/USBdrive (the folder where file systems without label will be mounted to) linking to this mounting point. And the data directory seems to be on the /media/USBdrive.
So I thought I would just move the NextCloud data directory to the real place, in /media/myCloudDrive. This somehow erased the data directory, but at least it made a copy before erasing it, so it was pretty easy to restore.
After restoring the data, I needed to move the data directory back to its original place. I thought this would be easy, just use the control center to move the data directory back to where it belonged. Sadly I made a spelling mistake, I moved it to /media/USBDrive (notice the upper-case "D").
This meant all the data would be moved all data from the HDD to the internal, very slow and too small SD-card. I thought I would just need to cancel the transition, but there was no cancel-button anywhere. So I just wanted to kill it using htop, but the process seemed to be uninterruptible, meaning it could not be killed. And the free space on the SD-card was shrinking pretty fast. Furthermore, because all I/O was taken up by the move, the OS (that runs on the internal SD-card) became pretty unresponsive, and the configuration-panel became completely inaccessible.
As the free disk space was growing to 0 (and even reaching it) and probably expecting many I/O-errors, I decided to rm the newly created directory.
After waiting way too long, it finished. I was able to move the data directory back to where it was. I tried it out and got a Internal Server Error, because why not. Checking back at the configuration panel, everything seemed fine. I reloaded the website, and it worked. What a climax.
I really hope it stays at a working state.
I have a pretty recent backup of all data on my NextCloud, so it will not be that bad loosing it all. But I really do not want to. I guess the conclusion should be to keep good backups and not to destroy your data when trying to do the backup.