I have scheduled backups running on my Pis. As part of my backup process, various services are stopped while the backup is running and started when the backup is complete. Being new to PiAware, I am configuring backups for it and have the following new services that need to be stopped while the backup is running…
piaware
dump1090-fa
skyaware978
gpsd
I’ve done some trial and error but can’t seem to get the start order correct. That is, after stopping the services, only a restart of the Pi gets PiAware working correctly again. I really don’t want to have to restart it after every backup so I’m hoping I can get the proper start order of these services that will result in PiAware functioning correctly.
Bullseye is Debian, in which stopping and restarting services during upgrade is automatic and user is not involved. Why you want to make it set by user?
But, @sjmarty is doing a backup not an upgrade. If you just do a reboot after the backup, everything should start up ok. It does for me, however I don’t have gpsd so don’t know about that one.
dump1090-fa has to be running to get piaware working. Not sure if piaware polls it once in a while to see if it is running.
For skyaware978 and your gpsd i cannot answer, but i would not expect dump1090-fa waiting for these.
Beside that on a linux device there is no need to stop services for doing backups, at least most of them. Some (like MySQL DB) are required for a cold backup, but i don’t see any of the above required to be stopped.
I am going to echo what others have said. The services listed are at most writing a log file. When the backup runs you either get the written log file or you don’t. You don’t have the problems you would have with a database or like file writes where it will be modifying the middle of a file. About the only thing that one might consider stopping the service would be for collectd (graphs1090) but was not noted in the original message.
That being said, if you are using gpsd, it needs to be the first started first as the location provided by the service is provided to dump1090 and skyaware978. You also need to put a pause before starting the dump1090 as sometimes getting a gps lock takes a bit and you would just get weird GPS locations of 00,00.
If you want kinda a middle road with stopping services, just don’t stop gpsd. I don’t think it even logs anything to system log and is most likely to give you issues when restarted.
Thanks for all the responses. I’m probably being overly cautious wanting to stop them but it’s just in the interest of getting good backups. I have one scheduled for tomorrow morning so I’ll give it a run with nothing stopped and see how it goes.
If anyone is interested, I am using raspiBackup. I have no affiliation with the author. I’m just a very satisfied user. This is Pi number six I’m running it on.
Well it’s been stated in other threads, a live backup is not completely safe. (How could it be)? However it seems to be safe enough, and I have done it many times with no apparent problems. For most of us, this is a hobby, and we aren’t talking about the family jewels here.
It will be completely safe as long as no files are in a locked state open in memory. These are typically things like a database file where the database is actively running. This you need to either shutdown or use specific routines for backing up such database files in open state.
Even the database of Virtual Radar Server (which is SQLite) can be safely backed up without shutting it down, because every access is written to the file directly and not to a transaction log.
Other files (e.g. var/log) are backed up in the state of the timestamp where the backup touched the file. Sou you are missing only the latest changes between backup and restore.
So, if you are concerned about the configuration files: As long as you are not changing it after the backup, nothing will happpen.
And beside that:
You have a backup on a specific timestamp. So the older it gets, the more out of date is it. That statement is valid for both cold and hot backup types
Backups have following advantages:
(1) Preserve historical data
(2) In case of software corruption or microSD card failure, easy restoration from backup.
For me:
Advantage (1) has no value as I have no use or interest in historical data…
Advantage (2) has no value as in case of software / microSD card failure, rather than using backup (which most likely be older version of everything), I prefer to re-image with latest version of OS and install the latest version of all feeders and graphs etc. This way my system is most up to date after restoration.
My interest in creating the how-to “cloning booted microSD card” was only technical. After creating that how-to 4 years ago, I never created any backup of any of my RPis’.
Well every one has his own preferences & choices. Your mileage may vary.
True. My view is that I have spent a lot of time installing packages on the RPi. If there’s a failure or corruption of the SD card, I don’t want to reinstall everything again by starting over with a clean install of a new system. So I do a (live) backup occasionally as a security blanket. So far I haven’t had to use the backup.
The disadvantage of my approach is that I can’t upgrade to Bookworm from Bullseye. I’m more or less stuck at Bullseye.
If I do: apt --installed list | wc -l
it shows 1001 packages installed on the Rpi at this point. That’s a lot of stuff to reinstall.
Edit to add: Of course some of those 1001 packages were there to begin with (part of the original system install). But a lot of them were installed after the system install.
But most of this stuff comes with the initial image on the SD card or as part of the install for a feeder package, so no additional workload.
I have tried several times and been able to rebuild an SD card from scratch within less than an hour for my setup. That’s why i never used backup.
A more accurate version for finding how many packages are installed: apt list --installed | grep "installed" | wc -l The first line of output is not a package. So there’s 1000 packages installed.
I don’t know how you guys can reinstall everything in less than an hour. It would take me more than an hour just to find everything that needs to be installed. I don’t even remember what I have installed. (That’s probably bad right there).
The reality is that just doing a plain install from an RPi Imager prepared SD takes less than a minute. Using the aforementioned package count revealed 686 installed packages. I checked the package count on one of my production feeders and the package count was 688. Presumably the additional two packages are FA & FR24. Overall It takes less than 10 minutes to setup and fully configure an RPi feeder from scratch. I do have a couple of RPi’s that have the desktop, CUPS, graphs1090, tar1090, skyaware along with a printer. Their package count is 1587 and 1643. In the past I have rebuilt both in less than 30 minutes including configuration. Configuration takes the most time.
