Snapshots on EX2300/EX3400

In this post I will discuss about snapshots on EX2300 and EX3400.

While the new FreeBSD version used in Junos releases after 15.1 is not specific to EX2300/EX3400, I will discuss more about them because I had access to these devices when I captured the outputs.

However everything is applicable to the other platforms like MX, QFX5k/10k, EX9200.

These platforms have two volumes and they are /dev/gpt/oam(OAM volume) and /dev/gpt/junos(Junos volume).

Junos volume is used for running device software and holds configuration information and logs while the OAM(Operations, Administration and Maintenance) volume holds a full backup that can be used in case something is going wrong with dev/gpt/junos.

There are two types of snapshots:

• non-recovery
  • resides on the Junos volume
  • points to the current set of packages and configuration at the time when the snapshot was taken
  • multiple non-recovery snapshots can be taken
  • they can be renamed
  • can be used to boot from them at the next reboot
• recovery
  • resides on the OAM volume
  • there can be only one at a time
  • can be used to recover the Junos volume
  • contains a full copy of the packages and configuration at the time when the snapshot was taken

At the time when I’m writing this, you can not check in a straightforward way too many details about the recovery snapshot like when it was created for instance.

So let’s see how you can work with non-recovery snapshots.

First this is the current release and platform:

{master:1}
root@EX3400> show version | match "Model|Junos:"
Model: ex3400-48p
Junos: 15.1X53-D55.5

{master:1}
root@EX3400>

This is how you can create a non-recovery snapshot:

{master:1}
root@EX3400> request system snapshot
fpc1:
--------------------------------------------------------------------------
NOTICE: Snapshot snap.20170223.114901 created successfully

{master:1}
root@EX3400>

This is how you can check the list of non-recovery snapshots:

{master:1}
root@EX3400> show system snapshot
fpc1:
--------------------------------------------------------------------------
Snapshot snap.20170223.114901:
Location: /packages/sets/snap.20170223.114901
Creation date: Feb 23 11:49:02 2017
Junos version: 15.1X53-D55.5

{master:1}
root@EX3400>

You can boot the device from it:

{master:1}
root@EX3400> request system snapshot load snap.20170223.114901
fpc1:
--------------------------------------------------------------------------
NOTICE: Loaded snapshot snap.20170223.114901.
NOTICE: This command requires a reboot to complete the operation.
NOTICE: To cancel this operation, run 'request system software rollback'

{master:1}
root@EX3400>

Or you can delete it:

{master:1}
root@EX3400> request system snapshot delete snap.20170223.114901
fpc1:
--------------------------------------------------------------------------
NOTICE: Snapshot 'snap.20170223.114901' deleted successfully

{master:1}
root@EX3400>

The non-recovery snapshots are store here:

{master:1}
root@EX3400> request system snapshot
fpc1:
--------------------------------------------------------------------------
NOTICE: Snapshot snap.20170223.125901 created successfully

{master:1}
root@EX3400> file list /packages/sets/

/packages/sets/:
active/
optional/
previous/
snap.20170223.125901/

{master:1}
root@EX3400>

There are several folders in /packages/sets that contain the list of all the components:

• active – currently running on the device
• previous – ran on the device before the upgrade

Although not a CLI command per se, you can read the content of the junos-release file from one of these folders to see for which Junos was taken:

{master:1}
root@EX3400> file show /packages/sets/previous/junos-release
15.1X53-D52

{master:1}
root@EX3400>

Now about recovery snapshots, they are created like this:

{master:1}
root@EX3400> request system snapshot recovery
fpc1:
--------------------------------------------------------------------------
Creating image ...
Compressing image ...
Image size is 243MB
Recovery snapshot created successfully

{master:1}
root@EX3400>

This does the same thing as “request system snapshot slice alternate” on the older platforms does.

You can recover the OAM volume:

{master:1}
root@EX3400> request system recover oam-volume
NOTICE: Recovering the OAM volume ...
da0p1 deleted
da0p1 added
/dev/gpt/oam: 500.0MB (1024000 sectors) block size 32768, fragment size 4096
    using 4 cylinder groups of 125.03MB, 4001 blks, 16128 inodes.
super-block backups (for fsck_ffs -b #) at:
 192, 256256, 512320, 768384
Verified oam signed by PackageProductionEc_2016 method ECDSA256+SHA256
Installing OAM volume contents ...
The OAM volume is now installed
NOTICE: Creating a recovery snapshot on the OAM volume ...
Creating image ...
Compressing image ...
Image size is 243MB
Recovery snapshot created successfully
NOTICE: OAM volume recovered

{master:1}
root@EX3400>

As mentioned, currently there is no direct way to check when the recovery snapshot was taken or which was the release at that time on the device.

However, you can find when the recovery snapshot was taken and then figure out what release you were using at that time by verifying the upgrades/downgrades history.

You need to mount the OAM volume and check like this.

root@EX3400:RE:1% mount /dev/gpt/oam /oam
root@EX3400:RE:1% ls -l /oam/snapshot/
total 498944
-rwxr-xr-x  1 root  wheel  255340544 Feb 23 11:59 recovery.ufs.uzip
root@EX3400:RE:1% df -h | grep oam
/dev/gpt/oam          484M    324M    121M    73%    /.mount/oam
root@EX3400:RE:1% umount /oam
root@EX3400:RE:1% df -h | grep oam
root@EX3400:RE:1%

IMPORTANT! Don’t forget to unmount the OAM volume.

And this is pretty much that non-recovery and recovery snapshots.

I hope you found this useful.

The following two tabs change content below.

• Bio
• Latest Posts

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Latest posts by Paris ARAU (see all)

• Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
• Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
• Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
• Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
• Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018