The heart of my backup script — kindly linked above by @BartoszP — is as reliable as computer software gets, being the version control system behind SQLite. Fossil not only keeps the SQLite project itself running, its repository format is an application of SQLite. Roughly a quarter of the C code in Fossil is its bundled copy of SQLite, and a good amount of Fossil’s power comes from its use of SQL queries into its repository DB.
cost-effective
This is all FOSS, from SQLite and Fossil to my backup script. The costs here are your time to configure and use it, and any storage fees you incur as a result.
easy to automate
I oppose periodic backups of RouterOS configurations on principle. Configuration backups should be taken at points where the admin decides a given change is settled enough to commit to the long-term version repository. (Further details in the linked article.)
Automated off-site storage of those same backups is another matter. I use a scheme based on this idea, which yields periodic snapshots into the types of cloud drive storage you reference.
That said, the Fossil scheme I use gives several backup layers before I have to resort to decrypting my periodic cloud snapshots:
- The checkout directory: Nearly every time I want to check how a given router is configured, I give a command like “vi ~/src/routers/gw/export.rsc” to pull it up. The first part references the directory where I have my router repository checked out on the local machine. This is not only a backup with respect to the routers in question, I keep the repo open on multiple machines, adding their local storage to the overall system redundancy.
- The local repository: Each machine from which I do network admin type things has a file like “~/museum/local/routers.fossil” which is the Fossil version repository backing the checkout directory.
- The remote repository: All machines I use have their Fossil repo clones automatically synced with at least one remote via the “fossil all sync” mechanism. This is typically either a central LAN server of some type or an off-site VPS in the cloud, decided on a per-repo basis. Router configs are too site-specific for me to want them synced off-site at this level, but that’s an admin decision, not a restriction of the tech.
That brings us full-circle, because that final “fossil all sync” step is one of the early steps in the script that creates my off-site encrypted backups. The result is four levels of backups, all managed by Fossil or wrapper scripts around it.
Now, since I see little point in creating these off-site fourth-level off-site backups more often than weekly, this local sync step is shadowed by my far more frequent manual calls to topgrade, which ships with built-in Fossil awareness, per its “Upgrade all the things” philosophy. In this manner, each machine where I do network admin things has its clone of the router configuration repository — and all the others cloned to that machine — updated on the same idiosyncratic non-schedule.
There are additional backup levels, being that of the machines where I do this work. There are copies of my router configuration Fossil repo in my local Time Machine backups, etc. I do not consider these primary since “fossil sync” is more trustworthy when it comes to syncing the DB reliably. Backup software + DBMS is a common way to turn happy admins sad.
and logs
The closest I get to automated backup of logs is setting my routers and switches up for remote logging. At home, that logging target is a SOHO grade NAS, which has its own backup strategy.
I would not sync logs to a cloud service. Local RAID mirroring suffices for all my use cases, but if ever I found myself in a world where off-site log backups were necessary, I’d expect them to be handled the same way I kept the remote logging server itself backed up, which is a fine exit point, being way off-topic here.