I updated my first RUTX11 to firmware 7.22. The first thing I always do is make a backup and compare it to the previous version to check for errors or settings drift.
In the backup.XXX.tar.gz file created by 7.22, the entire /etc/config directory is missing. I didn’t see anything about this in the release notes.
Please advise!
Greetings, @luckman212 ,
Thank you for reaching out!
I am currently working on this issue and I will inform you as soon as I have more information on the matter.
Best regards,
V.
Hello,
I hope you’re doing well,
I managed to replicate the issue and forwarded it to our R&D team for further investigation. I will update you on the matter once I have more information.
Best regards,
V.
Ok thank you. I am surprised this slipped by during testing. It’s somewhat concerning.
Also on a RUTX50, there are even more files and subdirectories of /etc missing, along with /etc/config. A few examples, when compared to a backup taken in 07.21.3 ….
/etc/crontabs
/etc/openvpn
/etc/profiles
/etc/profiles.d
… and many more
I hope someone has given the dev-testers a kick up the ****, as backup integrity is vital to an organisation’s recovery plan.
Greetings, @Mike ,
Thank you for your feedback,
And thank you for sharing that there are more missing files and directories from the backup. I have forwarded this information for our R&D team as it may be useful for further investigation.
I will post an update in this topic, once I have more information from our R&D team.
Best regards,
V.
I also did a backup on a RUTX50 and compared the 7.22 version with a 7.21 version. The only difference I could find where the uhttpd cert files that moved from the /etc directory to the /etc/certificates directory. No missing directories.
Before I run a backup I always run this command:
api Post /backup/actions/create_default
Maybe that can make a difference?
That explained why I did not experience the problem. I do backups the “old-fashioned way”. I run an Ansible playbook using the /sbin/sysupgrade -b command.
- name: Get backup file name
ansible.builtin.shell:
cmd: set -o pipefail && echo "${HOSTNAME}|$(/sbin/uci get system.system.device_fw_version)|$(/bin/date +%F)|$(/bin/date +%T).tar.gz"
register: backup_name
changed_when: false
- name: Perform backup
ansible.builtin.command:
cmd: /sbin/sysupgrade -b "/tmp/{{ backup_name.stdout }}"
register: backup_result
changed_when: backup_result.rc == 0
notify: Copy backup to local machineHello everyone,
I have an update regarding this matter.
The change in the backup structure is intentional and reflects a transition to a universal backup system. Instead of multiple configuration directories and files, the configuration is now consolidated into a single file located at /tmp/configuration.json.
You can modify the required settings within this file and then apply the backup accordingly. This backup format will continue to be used in future firmware releases. By editing the configuration.json file, you can control which settings from the backup are applied.
I hope this clarifies the changes. If you have any additional questions, please do not hesitate to reach out.
Best regards,
V.
I am still skeptical of the benefit of this “universal” monolithic JSON file vs the filesystem-adjacent method used previously.
The old system was very easy to store, modify, compress, compare, and validate. Now we have this huge mess of a JSON file which introduces novel ways to break the entire structure (stray comma, unescaped quote character, etc)
Also, as mentioned, it is an incomplete backup, missing certain things like crontab.
If this change is going to remain, I kindly request an API call to generate the “legacy” format backups.
e.g. on /backup/actions/generate :
{
"data": {
"encrypt": 0,
"format": "legacy | json (default)"
}
}
Also the in 7.22 introduced integrity feature at /integrity/actions/validate is file based. I use it to monitor file changes in my day-to-day backups.
@rvo that’s an interesting API for sure, but it’s hash-based. I just played around with it. It detects changed files, but you can’t diff the changes or see what they were. I had built up some tooling that relied on having access to the actual config file data. The integrity API isn’t a substitute for that.
To me it is more important to know that a file has changed than what the change is. I generate a baseline after each backup, and then run a validate just before the next backup. That way I get a confirmation nothing has changed that I do not know about. I don’t run a diff on my backup files.
You say tomayto, I say tomahto…
Can I ask what your next move is if your integrity check reports that a file was changed? Then what?
Most of the time I already know what files have changed, because I was the one that made the changes to the config.