FYI before you ' rm ' anything defined by a variable in bash, it's a good idea to put ' set -u ' before it, which will error out if the var is undefined.
If your microSD card dies and it takes the system down along with it because you yanked the power cable, that would suggest that you're NOT using a journaled file system like XFS (at minimum), etc. If you have a NAS or something that's a form of centralised data storage, I tend to keep as little on the individual clients itself, and keep as much of the data on said central server instead. Most people who have a NAS usually will be a physically bigger system, with support for more storage devices, which allows redundancy, and therefore; offers one layer of protection against the loss of data.
At the moment I've got all of my media data on an external SSD seperate to the microSD. I do plan to purchase a NAS and take everyone through what that looks like in the future -- that seems like the next logical step, I'm just keeping my home server extremely budget friendly for now. When you say I'm not using a journaled file system like XFS you may be right. I hadn't manually formatted the microSD card before I installed the Raspberry Pi OS. It looks like I have ext4 on my root volume and another small partition reserved for firmware which is vfat
@@techwithdavidolding "I do plan to purchase a NAS and take everyone through what that looks like in the future -- that seems like the next logical step, I'm just keeping my home server extremely budget friendly for now." Depending on how much you want to spend in terms of $/GB (or $/TB) of capacity for the NAS, there are a LOT of options out there now. (A LOT more than when I started.) If the performance of the NAS isn't hypercritical, especially if it is just a "dumb" NAS (i.e. it doesn't do anything else except serve up data over NFS/SMB/CIFS/AFP and/or maybe iSCSI, then as long as it can support line speed, then it will work, as a NAS). "It looks like I have ext4 on my root volume and another small partition reserved for firmware which is vfat" So....ext4 is supposed to be journaled, but I can also envision a scenario where depending on how often it populates and flushes said journal, that it can create problems. But sometimes, it will fail to boot, and you just basically have to tell it to replay or repair the journal (via journalctl in Ubuntu (not sure about RPi OS)), and that should clear it up. Usually.
Excellent video! A tip for you: instead of holding up a SD card or rpi close to the camera, record a second clip and edit them together to avoid this autofocus thing
Thanks for the tip. You're right - we call that B Roll footage, which I'll look to do a bit more of in future. For this intro I purposely wanted to hold it up and physically showcase it in my hands so it felt like I was genuinely just having a conversation with you guys. But what I should have done is disabled face tracking -- and adjusted my auto focus settings to the fastest level. A lesson for next time 😆
The sad reality is most people don't take backups seriously until something catastrophic happens, at which point it's too late of course. Best practice for git/ansible aside having a working tested backup regime is always a good thing.
@@ewenchan1239 Part curiosity and part laziness to be honest. I want to see how long my current setup will last for this time around, and I also can't be bothered making the switch right now. However I probably will do it soon - especially if it results in a performance improvement as well :)
@@techwithdavidolding "Part curiosity and part laziness to be honest." But if you can PREVENT a failure before it happens, prevention (active management) is pretty much almost always better than reactionary management (where it's the "oh shit" moment that something has failed, and you have to go into the system ex post facto, to try and recover the system vs. doing the clone now, whilst everything is still working well. "However I probably will do it soon - especially if it results in a performance improvement as well :)" I don't know how much of a performance benefit you may or may not be able to realise due to the Raspberry Pi processor itself, but for data protection reasons, and to prevent taking all of your services down; cloning it now would probably be less of a headache then when/if the microSD fails again, and you can to re-deploy the system again.
Great video!!! I wanna share you how I do it store the backup properly on another storage (such as a cloud storage), then define your Home Server as code using Ansible. So, next time your Pi goes boom boom, you can get your server up and running in one click. with out losing the data
I don't store much on the actual microsd card. Why not create an image of the entire card? Just have a couple on hand that are the same size and you can duplicate the image on a fresh microsd card.
That could work as well. I generally have a bias towards coding my infrastructure setup rather than the traditional snapshot/imaging way of doing things.
Never trust SD card, they are so unstable. I have been using them for IP cameras, after some period of time it just stop working good / generates some errors, so you have to format it. I heard from some youtube photograp that he formats his microsd card every 20 days to avoid bugs.
Nice content, I subscribed. you could explain the git part faster. and need a better microphone. I feel your channel is gonna be the next big thing.❤🔥
FYI before you ' rm ' anything defined by a variable in bash, it's a good idea to put ' set -u ' before it, which will error out if the var is undefined.
If your microSD card dies and it takes the system down along with it because you yanked the power cable, that would suggest that you're NOT using a journaled file system like XFS (at minimum), etc.
If you have a NAS or something that's a form of centralised data storage, I tend to keep as little on the individual clients itself, and keep as much of the data on said central server instead.
Most people who have a NAS usually will be a physically bigger system, with support for more storage devices, which allows redundancy, and therefore; offers one layer of protection against the loss of data.
At the moment I've got all of my media data on an external SSD seperate to the microSD.
I do plan to purchase a NAS and take everyone through what that looks like in the future -- that seems like the next logical step, I'm just keeping my home server extremely budget friendly for now.
When you say I'm not using a journaled file system like XFS you may be right.
I hadn't manually formatted the microSD card before I installed the Raspberry Pi OS.
It looks like I have ext4 on my root volume and another small partition reserved for firmware which is vfat
@@techwithdavidolding
"I do plan to purchase a NAS and take everyone through what that looks like in the future -- that seems like the next logical step, I'm just keeping my home server extremely budget friendly for now."
Depending on how much you want to spend in terms of $/GB (or $/TB) of capacity for the NAS, there are a LOT of options out there now.
(A LOT more than when I started.)
If the performance of the NAS isn't hypercritical, especially if it is just a "dumb" NAS (i.e. it doesn't do anything else except serve up data over NFS/SMB/CIFS/AFP and/or maybe iSCSI, then as long as it can support line speed, then it will work, as a NAS).
"It looks like I have ext4 on my root volume and another small partition reserved for firmware which is vfat"
So....ext4 is supposed to be journaled, but I can also envision a scenario where depending on how often it populates and flushes said journal, that it can create problems.
But sometimes, it will fail to boot, and you just basically have to tell it to replay or repair the journal (via journalctl in Ubuntu (not sure about RPi OS)), and that should clear it up. Usually.
Excellent video! A tip for you: instead of holding up a SD card or rpi close to the camera, record a second clip and edit them together to avoid this autofocus thing
Thanks for the tip.
You're right - we call that B Roll footage, which I'll look to do a bit more of in future.
For this intro I purposely wanted to hold it up and physically showcase it in my hands so it felt like I was genuinely just having a conversation with you guys.
But what I should have done is disabled face tracking -- and adjusted my auto focus settings to the fastest level.
A lesson for next time 😆
The sad reality is most people don't take backups seriously until something catastrophic happens, at which point it's too late of course. Best practice for git/ansible aside having a working tested backup regime is always a good thing.
A good idea is to use SSD instead of SD for RPI - they are much more reliable (and faster as a bonus.)
That's a really good point.
I'll wait for the next hardware failure then make the switch 😂
@@techwithdavidolding
Why wait when you can clone the drive now BEFORE the next time it fails?
@@ewenchan1239 Part curiosity and part laziness to be honest.
I want to see how long my current setup will last for this time around, and I also can't be bothered making the switch right now.
However I probably will do it soon - especially if it results in a performance improvement as well :)
@@techwithdavidolding
"Part curiosity and part laziness to be honest."
But if you can PREVENT a failure before it happens, prevention (active management) is pretty much almost always better than reactionary management (where it's the "oh shit" moment that something has failed, and you have to go into the system ex post facto, to try and recover the system vs. doing the clone now, whilst everything is still working well.
"However I probably will do it soon - especially if it results in a performance improvement as well :)"
I don't know how much of a performance benefit you may or may not be able to realise due to the Raspberry Pi processor itself, but for data protection reasons, and to prevent taking all of your services down; cloning it now would probably be less of a headache then when/if the microSD fails again, and you can to re-deploy the system again.
Great video!!!
I wanna share you how I do it
store the backup properly on another storage (such as a cloud storage), then define your Home Server as code using Ansible. So, next time your Pi goes boom boom, you can get your server up and running in one click. with out losing the data
Or even better: use nixOS
@@RegrinderAlert Never heard of it but damn NixOS is real cool.
That's a great way of doing it!
Did you just delete the old backup before taking a new one? 😢😮
Yuppp 😂
You raise a good point -- I should probably do the clean up of old backups AFTER a new successful backup has been completed.
I don't store much on the actual microsd card. Why not create an image of the entire card? Just have a couple on hand that are the same size and you can duplicate the image on a fresh microsd card.
That could work as well.
I generally have a bias towards coding my infrastructure setup rather than the traditional snapshot/imaging way of doing things.
Never trust SD card, they are so unstable. I have been using them for IP cameras, after some period of time it just stop working good / generates some errors, so you have to format it. I heard from some youtube photograp that he formats his microsd card every 20 days to avoid bugs.
Yikes - yeah now that I have the backups configured it's not such a big deal.
But I will be moving to an SSD some time in the future.
Nice content, I subscribed.
you could explain the git part faster.
and need a better microphone.
I feel your channel is gonna be the next big thing.❤🔥
Appreciate the feedback.
I'll look to upgrade the audio soon 😄