Juniper keeps a bunch of config backups, but how do we use them?
In this video, we're looking at how to rollback our changes and restore backups.
The command model is probably my favorite Junos feature,
but we've only seen half of its power so far.
There's an extra feature called Commit Confirmed,
which really gives Junos an extra edge.
Imagine that you're working on a router at a remote office.
If you make a mistake, you might lose access to the router.
Maybe you change an IP he calls a routing loop or something like that.
With another vendor, we might need to schedule a restart before we begin.
Call someone on site
and get them to restart the router or maybe even travel out there ourselves.
In any case, it's all disruptive
This is not so with Junos.
Junos has a fantastic commit confirmed feature.
If we run this command, our changes will be committed
and a ten minute timer will start.
We can use a different time if we wish.
If we don't confirm
that these changes are good, Junos automatically rolls back our changes.
This is a quick way to automatically recover
if we give Junos bad config.
In our example, we waited too long and our changes
rolled back
Let's make those changes again
and commit them
If we're happy with our changes this time,
we can run another commit to confirm they are good
and that's just the first level of rollback that's available to us.
Before we look at the next options.
Let's take a quick look at how Juno's handles config file backups
Every time we commit a change.
A copy of the config is compressed and stored in the config directory.
We can see the contents of this directory
or any other for that matter, with the file list command.
Optionally, you can add the detailed keyword to get a Linux like output
see the file.
Juniper dot com gz.
This is the active configuration file.
Also notice additional files
named with one to three and so on.
These are backups of previous active configuration files.
When we commit changes we are moving the candidate config to the active config.
While this is being done, genus rotate these files
juniper dot com gz becomes juniper dot coms, one dot gz
one becomes two, two becomes three, and so on.
The files we see here are the most recent files so they kept on fast storage,
but that's not the end of it.
There are additional backups in slash via slash db slash config
This, which I'm using here is a low end switch and doesn't have multiple disks.
So this is just a pointer back to slash config slash db slash config
A bigger device has fast and slow storage.
This location would normally be on slow storage
and would keep backups for through to 49
So we've got a whole bunch of backups.
That's great. But what do we do with them?
Let's imagine that we start making changes and then realize
that we've made a mistake.
We can't just exit as we get an error.
We also don't want to commit our mistake.
So what can we do?
We can roll back the candidate config to the active config
using rollback zero or simply just rollback.
This was the active config that is Juniper
dconf dot gz as the candidate config
On occasion we might make a mistake and then committed.
In this case we can use a different rollback point.
For example, rollback one
Sometimes it can be tricky thinking about which.
No, we want a rollback to
think of it as the number of commits that you want to reverse.
Take note though.
That this just loads the back up into the candidate config.
You will still need to commit this if you want it to take effect.
Here's another helpful hint.
If you're not sure which rollback point you want to use, you can compare it
to the candidate to see the changes you've made since that point.
One last thought around config backups.
If we want, we can manually back up the candidate
config to disk with the save command This will create a file
in the user's personal directory under slash via slash home
If we want to restore this file later,
we can use the load or load override command.
You can try this in the associated lab if you want to
And now it's quite time again.
I hope you're getting some value from these.
I spent a lot of time putting them together.
Let me know what you think in the comment section.
What we've seen here is another fantastic reason to use Juniper devices.
It's so easy to track configuration changes and roll back to them
Click the next video to see how we can create
config templates using configuration groups.