Configuration Backup

[WX4JCW]

Would it be possible to back up the CSS data on custom setups when you backup the system configuration? or did I miss something

[KN2TOD]

The dashboard color codes can be saved by manually copying the /etc/pistar-css.ini file out during backups and reloading it during restores. Alternately, one can apply the following patch to the backup/restore process:

Code: Select all

rpi-rw
sudo sed -i 's/pistar-remote $backupDir 2>\&1");/pistar-remote $backupDir 2>\&1") ;\n\t  $output \.= shell_exec("sudo cp \/etc\/pistar-css.ini $backupDir 2>\&1");/1' /var/www/dashboard/admin/config_backup.php
sudo sed -i 's/backed up and restored<\/li>/backed up and restored <\/li>\n\t\t  <li>Dashboard color codes ARE also backed up and restored<\/li>/1'  /var/www/dashboard/admin/config_backup.php
rpi-ro

Astute users will note that this changes the backup process to include the applicable file but does not add anything to the restore process - the restore portion of the process is already set to handle the extra file. What this means is that a backup taken with a patched system can be restored on an unpatched system (such as a new image) without first applying the patch.

[AF4FA]

The dashboard color codes can be saved by manually copying the /etc/pistar-css.ini file out during backups and reloading it during restores. Alternately, one can apply the following patch to the backup/restore process:

Code: Select all

rpi-rw
sudo sed -i 's/pistar-remote $backupDir 2>\&1");/pistar-remote $backupDir 2>\&1") ;\n\t  $output \.= shell_exec("sudo cp \/etc\/pistar-css.ini $backupDir 2>\&1");/1' /var/www/dashboard/admin/config_backup.php
sudo sed -i 's/backed up and restored<\/li>/backed up and restored <\/li>\n\t\t  <li>Dashboard color codes ARE also backed up and restored<\/li>/1'  /var/www/dashboard/admin/config_backup.php
rpi-ro

Astute users will note that this changes the backup process to include the applicable file but does not add anything to the restore process - the restore portion of the process is already set to handle the extra file. What this means is that a backup taken with a patched system can be restored on an unpatched system (such as a new image) without first applying the patch.

Will this patch have to be reapplied each time there is an update to the version unless it is added to the system by Andy?

[KN2TOD]

Afraid so. But how often does one typically make config backups? Apply it if and only if you need it, just before taking a backup. Copy the commands to a .SH file so you can (re)run when needed. (Also, the commands can be rerun multiple times, on an already patched system, without ill effect.) You can tell when the patch has been removed - the extra verbiage will be gone at the bottom of the backup/restore dashboard.

Still, it would be nice if it were folding in to the base system.

[KN2TOD]

I should add that I tested this modification for a single scenario: restoring a config to a new image, one that had CSS changes. Other scenarios (for instance, no CSS changes) need to be tested. And the modification was applied to fairly current systems (4.1.1 and 4.1.2) but not to any earlier versions, although the code change is simply enough it should still work.

Need more folks to try this out and give us some feedback.

[MW0MWZ]

This was excluded from the backup on purpose, however the reasons for excluding it are rather less valid now, I will add it in soon.

[EA3BIL]

This was excluded from the backup on purpose, however the reasons for excluding it are rather less valid now, I will add it in soon.

Sorry to take this "Back to Live"...

Just a simple question:

Is CSS it now been backuped ??

Thanks for your comments !!

73'Rafa.
EA3BIL.

[kt4lh]

Same question here; backing up the CSS is trivial, just a line added to a file, but that's not really sustainable to edit the file frequently. Is there a reason the CSS Isn't backed up?

[MW0MWZ]

there was a good reason, when it was all new

Now part of the backup.