ZFS Snapshot
From Genunix
Contents |
ZFS Snapshot and Rollback - Phase 0 GUI ideas
Introduction
This page contains ideas for a GUI based on Tim Foster's snapshot and backup SMF services.
Snapshot Idea 0
See feedback on this mockup on the OpenSolaris forums
This example starts with a system on which the correct ZFS pools/filesystems are enabled (see note at step 2). Aim is to create automatic snapshots of our Documents folder.
1. User right-clicks the file they wish to enable snapshots for. Nautilus menu includes an "Enable Automatic Snapshots" menu item. (Have just discovered that Nautilus extensions can add menu items to the main menu bar too, so this menu item should definitely live in there somewhere as well):
2. User selects "Enable Automatic Snapshots". Menu item should be disabled or hidden if the folder is not part of a ZFS filesystem. (If that's not possible, keep it enabled all the time and pop up an error message, I suppose.)
Note: original requirements said to present a GUI to allow the user to create a ZFS pool at this point, but for Phase 0 would it be too unreasonable to set up ZFS pools/filesystems manually?
3. Nautilus file properties dialog opens, with Snapshot tab frontmost, and "Save snapshots of this folder automatically" box checked. Now user gets to choose how often to take snapshots (every n mins, hours, days, weeks or months), what time/day to start, and how many to keep:
The "Starting at" controls would have to change depending on the interval chosen (mins, hours, days, weeks or months). Tim says there are a couple of bugs here, so we might need to fudge things a bit. He also mentioned that it's possible to have multiple schedules for the same filesystem or group of related filesystems, but IMHO we shouldn't worry about that for Phase 0.
The "Snapshot Now" section of the dialog allows you to take a named snapshot immediately. Maybe a button on the nautilus toolbar for this would be useful too.
4. Once snapshots are enabled for a folder, it's given a natty Nautilus emblem:
6. When user right-clicks such a folder, the 'Enable Automatic Snapshots' menu item has been replaced by 'Restore from Snapshot...':
Which opens a dialog:
Calendar widget shows days in bold for which snapshots exist. Table on left lists the times and names of the snapshots-- note that all existing snapshots are shown here, not just ones that were generated by the auto snapshot service.
"Open" button opens the selected snapshot in nautilus --> Step 7 below.
"Roll Back" button restores the entire filesystem (with a confirmation dialog-- need to warn the user that this will delete _all_ snapshots that have been generated since then!) If user elects to do that, we're done and the next step is skipped. (Is this button really useful, or just dangerous?)
7. Selecting a snapshot to Open shows its contents of that snapshot in the file manager, with a banner as per the nautilus Trash and CD/DVD Burner windows. The banner should stay visible even when browsing into subfolders of the snapshot.
Back/forward buttons up in the blue header cycle through the available snapshots. Restore Files button is enabled by default.
- If Restore Files clicked while no files are selected, give choice of restoring file system (deletes all intermediate snapshots), or copying all files back to 'live' folder (no snapshots deleted).
- If 1 <= n < all files are selected, Restore Files copies the files back to the 'live' folder.
For Phase 0 at least, the nautilus address bar should just show the physical snapshot pathname, e.g. /home/user/Documents/.zfs/snapshot/snapshotname. Maybe we can do something with virtual pathnames (cf. the Trash and CD/DVD burner locations) in later Phases, if required.
TODO: What to do when browsing down from here into a folder that's on a different snapshot schedule, e.g. I'm snapshotting Documents once a day, but Documents/Important every hour? Ideally, I guess you'd maybe open the nearest corresponding snapshot for that folder (i.e. the last snapshot that was taken no later than the parent folder's snapshot) in a new window. No idea how you'd implement that, though :)
TODO: Would we want an option to restore files to a location other than the 'live' folder/filesystem? Probably not a Phase 0 requirement.
Snapshot Idea 1
User chooses Edit->Snapshot Manager in Nautilus (menu item implemented via nautilus extension). The snapshot manager dialog appears:
The left hand side of the dialog lists all snapshot schedules that have been set up, each has a user-defined name and description. We might provide some by default (daily, weekly, monthly), but the user can edit them.
User can add or delete named schedules using the + and - buttons (cf. bookmarks in nautilus side pane and GNOME file dialogs).
Right-hand side of dialog, top: a tree view of all zfs pools and their filesystems. Here the user checks/unchecks those filesystems to be backed up by the selected schedule. Checkmark indicates that all sub-filesystems (if any) are also checked. Indeterminate mark indicates that some but not all sub-filesystems are checked. (Assumes that a sub-filesystem can't be checked without its parent being checked-- is this true? I.e. could I snapshot MyPool/Documents/Important without also snapshotting MyPool/Documents?)
Right-hand, bottom: Sets the frequency of snapshots and the number to keep, much like Design Idea 0.
Close button closes the window.
Restore buttons opens the "Restore" sub-dialog:
Controls on left allow the user to select a historical date, and whether to list snapshots taken before, on or since that date.
Right-hand side lists all those snaphots on/before/since the selected date that were taken by the schedule selected in the previous dialog-- i.e. in this example, the "Important Documents" schedule.
Browse button opens nautilus window at root of snapshot, similar to Design Idea 0:
- What to do if there are multiple roots? Could open multiple windows, but would ideally want to keep them in sync if using the back/next buttons to cycle through snapshots... sounds ugly.
- As it stands, this design doesn't provide any way to restore from manual snapshots, only scheduled ones. Might not be a problem for a Phase 0 design.
