File and Object Storage

Keeping your data safe is not easy these days as attacks get more sophisticated. Spectrum Scale can help you in the following ways:

1. Compartmentalize by providing an external filesystem
2. Versioning of files by using snapshot technology
3. Replicating immutable backups to cloud storage

In this blog we'll create snapshots manually, schedule them, and restore from them.

Snapshots are an integrated feature of Spectrum Scale and are created in an instant by locking the metadata and data to a point in time. Any changes in the filesystem afterwards are resolved using Copy-On-Write (COW) on a block level. So as the files change in a filesystem, the snapshot "uses" more an more space. Having many snapshots can fill up your filesystem, so be aware!

You can create snapshots on a filesystem level, or on a fileset level. Only independent filesets support snapshots, as they have their own inode administration. We'll keep it simple and snapshot the whole filesystem, including all filesets:

# echo "This is a very important file" > /nas1/special.txt
# mmcrsnapshot nas1 snap1
Flushing dirty data for snapshot :snap1...
Quiescing all file system operations.
Snapshot :snap1 created with id 1.
# mmlssnapshot nas1
Snapshots in file system nas1:
Directory                SnapId    Status  Created                   Fileset
snap1                    1         Valid   Mon May 24 11:41:14 2021 

You can view the contents of the snapshots in the root of the filesystem:

# ls -l /nas1/.snapshots/snap1
...
-rw-r--r-- 1 root    root           30 mei 24 11:48 special.txt
...

Snapshots are by definition read only, so you can copy files out of the snapshot, but cannot add anything, so snapshots are safe from corruption and unintended encryption. Let's see that in action:

# echo "54*%765*&%&*&^8&^9&" > /nas1/special.txt
# echo "54*%765*&%&*&^8&^9&" > /nas1/.snapshots/snap1/special.txt
-bash: /nas1/.snapshots/snap1/special.txt: Read-only file system

 A restore cannot be performed directly if the file still exists, as the file (inode) is the same because of the snapshot COW. So either restore to a different directory, delete the file first, or tar or rsync:

# cp /nas1/.snapshots/snap1/special.txt /nas1/special.txt 
cp: '/nas1/.snapshots/snap1/special.txt' and '/nas1/special.txt' are the same file
# mkdir /nas1/restore
# cp -p /nas1/.snapshots/snap1/special.txt /nas1/restore

If there is more than one file affected, you can restore the whole filesystem at once from a snapshot with the mmrestorefs command. Be careful here, real UNIX commands have no "Are you sure?" prompt, if you ask for it, you'll get it.

# mmrestorefs nas1 snap1
[2021-05-24 12:08:12] Restoring filesystem "/dev/nas1" from snapshot "snap1" 
...
[2021-05-24 12:08:22] Restore completed successfully.
[2021-05-24 12:08:22] Clean up.
# cat /nas1/special.txt
This is a very important file

Deleting a snapshot manually is simple:

# mmdelsnapshot nas1 snap1
Invalidating snapshot files in :snap1...
Deleting files in snapshot :snap1...
 100.00 % complete on Mon May 24 11:47:12 2021  (    166912 inodes with total          4 MB data processed)
Invalidating snapshot files in :snap1/F/...
Delete snapshot :snap1 successful.

Now we have seen this is all working fine, let's automate the snapshots using the GUI. GO to the files section, then snapshots, and "Create Snapshot". Instead of "Manual", choose the "Schedule" tab. In the Path select the mount point of the filesystem.

As we have no schedule rule yet, click "Create Rule":

This should be self explanatory, Except for the "Prefix". That value is the Greenwich Mean Time, in a format that SMB shadow copy understands so that Windows client can use the "Previous Versions"

 
You will end up with a lot of snapshots, each of which will take some space. The space usage cannot easily be seen using the "df" command, it requires analysis of the filesystem using the mmlssnapshot command.

# mmlssnapshot nas1 -d
Snapshots in file system nas1: [data and metadata in KB]
Directory                SnapId    Status  Created                   Fileset           Data  Metadata
@GMT-2021.05.18-01.00.01 4         Valid   Tue May 18 01:00:00 2021                   12288     12576
@GMT-2021.05.19-01.00.01 5         Valid   Wed May 19 01:00:00 2021                  233480     12576
@GMT-2021.05.20-01.00.01 6         Valid   Thu May 20 01:00:00 2021                  103424     12576
@GMT-2021.05.21-01.00.01 7         Valid   Fri May 21 01:00:00 2021                  512000     12576
@GMT-2021.05.22-01.00.01 8         Valid   Sat May 22 01:00:00 2021                       0     12576
@GMT-2021.05.23-01.00.01 9         Valid   Sun May 23 01:00:00 2021                  299016     12576
@GMT-2021.05.24-01.00.01 10        Valid   Mon May 24 01:00:00 2021                       0      8224