It’s incredibly slow on a Pi3B but I don’t know if that’s due to network speed to the NAS or just the speed of the Pi itself. It took an hour and a half to backup a 16Gb card.
A nice touch is being able to disable and enable services so I’ve told it to stop vnstat while it’s doing the backup so it doesn’t mess with my daily network statistics.
That’s in my loft and has no additional cooling - I wouldn’t normally run it during the day so the ambient temperature will be lower overnight by at least 10°C. It didn’t throttle at all though so that’s good.
It’ll be interesting to see how well it runs on the main Pi up my mast overnight.
Run backup script by following command. Pass the backup partition as last parameter when invoking raspiBackup. sudo bash ./raspiBackup.sh -a : -o : -z -m detailed /home/pi/Windows-Share
If no dd backup should be created pass the backup type tar or rsync with option -t , e.g. sudo bash ./raspiBackup.sh -t tar or sudo bash ./raspiBackup.sh -t rsync
Help for all other options of raspiBackup is displayed with bash ./raspiBackup.sh -h
-General options-
-b {dd block size} (default: 1M)
-D "{additional dd parameters}" (default: no)
-e {email address} (default: no)
-E "{additional email call parameters}" (default: no)
-f {config filename}
-g Display progress bar
-G {message language} (EN or DE) (default: EN)
-h display this help text
-l {log level} ( Debug | Off) (default: Debug)
-m {message level} ( Detailed | Minimal) (default: Minimal)
-M {backup description}
-n notification if there is a newer scriptversion available for download (default: yes)
-s {email program to use} (mail,ssmtp,msmtp,sendEmail,mailext) (default: mail)
--timestamps Prefix messages with timestamps (default: no)
-u "{excludeList}" List of directories to exclude from tar and rsync backup
-U current script version will be replaced by the most recent version. Current version will be saved and can be restored with parameter -V
-v verbose output of backup tools (default: no)
-V restore a previous version
-z compress backup file with gzip (default: yes)
-Restore options-
-0 SD card will not be formatted
-1 Formatting errors on SD card will be ignored
-C Formating of the restorepartitions will check for badblocks (Standard: 0)
-d {restoreDevice} (default: no) (Example: /dev/sda)
-R {rootPartition} (default: restoreDevice) (Example: /dev/sdb1)
--resizeRootFS (Default: yes)
This one took an hour and a half but was running simultaensously with my Pi4 which took 52 minutes so again, the NAS could have been a slight bottleneck. I’ve just got the Pi4 running overnight tonight so will see how long it takes.
I’ve now got them running on alternate nights just so I can monitor them until I’m happy everything is good and then I’ll reduce them to once a week.
@NeoDuder The gzip “Input/output error” seems to be the key. Could be many things. How much free space is on your sdcard? Do you have other processes beyond ADS-B stuff that might be interfering?
It’s been running weekly on my two RPIs for me with no problems. Well it does cause Airspy to drop a few messages for a few seconds each time in runs, but no big deal…
For me cloning this over the network taking an hour doesn’t make really sense. Such a card can be copied to an image within 10 Minutes by using the SDCard slot on a computer/laptop.
That’s my logic here as well. I have seven Pis which I backup to my NAS, each one gets done once a week and I keep six weeks worth of backups. I check them every few weeks just to make sure that they’re still backing up and that the .msg file created shows a success. I don’t want to have to do this manually and the installs on these Pis would take too long to rebuild if I had to do them by scratch,
It makes me a lot more comfortable knowing I have backups that I can restore if I need.
If it’s ADS-B only, why is a weekly full backup required? Do you have so many changes?
Image it once and then run the incremental backup via network
I would understand it for other devices with a different purpose. But a Flightfeeder?
My devices are running without backup. I only copy once a day the VRS database.
If one fails, well, then i reinstall it with all feeders in approx 90 Minutes
I am not complaining, just asking for my understanding. You can of course do however you like to do it.
@foxhunter I do frequent manual updates of my databases. I run multiple ADSB feeders as well as TAR1090, Timelapse1090, Graphs1090. My Dump1090 map has lots of customisations which I am constantly adding to and adjusting. Just makes sense to have a full backup every week.
Sidenote: I got this working. Rebooted my pi and now it works no problem.
There is merit to using a large SD card however - writes get spread across the medium creating a longer MTBF. If anyone is using a Pi, they can run the entire thing from a USB stick or attached HDD/SSD and not worry about SD card degradation at all as they aren’t required to boot with the proper firmware.
As in our shops there are almost no cards 16GB or smaller available and the 64GB versions are always the faster ones, the decision for it was easy.
And several tests showed that larger cards can have a longer reliable runtime