Printable View
I read the documentation, but am a little unclear on snapshot functionality.
What I wish to do is create a snapshot for the morning, one for the afternoon, and one for the evening which is backed up. I want to do this so I have a variety of restore points to choose from for file-level restore during the day, and get a full backup at night.
How should I configure the 3 snapshots?
You will need to create 4 snapshots, the first one is reserved for the system the other 3 are used for the scheduled Snapshots located in the Disk Manager. Here is some important information on how to setup the schedule as well as accessing the data from a snapshot.
Accessing the snapshot to restore, is done manually by selecting the files or directories from the Snapshot directory. Recommended reserved space for Snapshot is at least 10% of the total storage capacity of the data in use for current and future. This is then located in each Snapshot filer (snap002, snap003 and so on) where stored. The storage of all changes is independent of the file-system Open-E NAS-XSR uses on block-level.
Only when the snapshot is deleted / removed the changes are permanently transferred to the actual data volume. Through a separate share, which is only available for the administrator (or backup administrator), a complete backup of the dataset can be done. Up to 100 snapshots can be stored for a long history of the dataset.
The Snapshot function is perfectly transparent for the users in the network.
Only the administrator can work with the Snapshots. You can have up to 100 Snapshots with scheduled times.
Snapshots can be activated/deactivated manually or automatically. In the
schedule options "Begin time" and "End time" and day of week are used for
automatic snapshots: this is the time of automatic activation and deactivation
(syntax is “him”). When snapshot start is set, the snapshot will be deactivated
and activated again at the given time. Alternatively, snapshots can be taken manually in the Maintenance �� Snapshot menu even if snapshots are automatically created under “Snapshot Definition”. Button remove all can by useful for removing all snapshot at one time. Snapshots are shared via SMB/CIFS protocol, but for authenticated users only.
Access to snapshots can be granted in Maintenance �� Snapshot. Recommendation: Use only as many active snapshots as really needed – a large count of active snapshots can slow down the system considerably. Please be reasonable, when you are calculating the space reserved for snapshots. Please set as snapshot size as much space as you expect
to change during active snapshot. E.g. when you are doing backup from snapshot which takes one hour please set this snapshot size to as much space that will be changed during one hour. The snapshot will become inactive if the content (data changed on Logical Volume) exceeds the snapshot capacity. You do not lose data in that case, just the dataset, which is virtual for the users at the moment, will be written to the data volume. The old dataset, which has been frozen with the snapshot, is not available any longer.
Configuration example:
Snapshot Res.% Begin End
Snapshot02 50% 6:45 N.A.
Snapshot03 5% 10:00 10:30
Snapshot04 10% 13:00 13:40
Snapshot05 10% 15:00 16:00
Snapshot06 1% 16:00 22:00
This example is suitable for companies that start working at 7 am and end
around 3 pm. Every morning - before everybody starts working - snapshot02 will by created (refreshed). This snapshot is designed to hold data from the beginning of
working day untouched to the end of the day. This will enable simple access to
files changed at the same day in order to look at previous file version.
After three hours of work, the second snapshot (03) will by created and will stay
active for 30 minutes. At this time, the backup server (Brightstor, for example) will
connect to clients that are running Open-e NAS and backup all data. This same
situation repeats at 1 pm and 3 pm - but with one difference - at this time, there
is much greater activity (many more files are written), because at 3 pm all
changes are stored in expectance of leaving off work. The last snapshot with only 1% reserved space is forerunning backups on a tape device with a backup server. This backup takes much more time as backing up one single hard drive.
Thanks for the reply, but most of it is the exact text from your manual which I read and was unable to fully conceptualize snapshot interaction.
Let me rephrase.
If I have snapshot002 start at 08:00 with no end time
and I have snapshot003 start at 12:00 with no end time
and I have snapshot004 start at 16:00 with no end time
-How will changes get updated to the main volume?
-Will changes made between 8:00 and 11:59 not get written to the main volume until 08:00 the following day, and therefore not be present in snapshot003 or snapshot004?
-If I set my backup to hit snapshot004 at 23:59 will it capture all changes made to the system that day?
Thanks in advance,
K
If no end time is set then they will be active until they are manually
stopped (or filled 100% then re-written to beginning). We use a copy-on-write technology
below is a description.
Changes are made throughout your schedule to the main volume. If setting up multiple Snapshots try not overlapping them to the same volume. The backup will capture all data that is scheduled in Snapshot so this would be continuous. Try setting end times.
snapshot002 at 8:00 - 12:00
snapshot003 at 12:00 - 18:00
snapshot004 at 18:00 - 23:59
Snapshot technology
Copy-on-write (sometimes referred to as "COW") is an optimization strategy used in computer programming. The fundamental idea is that if multiple callers ask for resources which are initially indistinguishable, you can give them pointers to the same resource. This fiction can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers. The primary advantage is that if a caller never makes any modifications, no private copy need ever be created.
Copy-on-write finds its main use in virtual memory operating systems; when a process creates a copy of itself, the pages in memory that might be modified by either the process or its copy are marked copy-on-write. When one process modifies the memory, the operating system's kernel intercepts the operation and copies the memory so that changes in one process's memory are not visible to the other.
Another use is in the calloc function. This can be implemented by having a page of physical memory filled with zeroes. When the memory is allocated, the pages returned all refer to the page of zeroes and are all marked as copy-on-write. This way, the amount of physical memory allocated for the process does not increase until data is written. This is typically only done for larger allocations.
Copy-on-write can be implemented by telling the MMU that certain pages in the process's address space are read-only. When data is written to these pages, the MMU raises an exception which is handled by the kernel, which allocates new space in physical memory and makes the page being written to correspond to that new location in physical memory.
One major advantage of COW is the ability to use memory sparsely. Because the usage of physical memory only increases as data is stored in it, very efficient hash tables can be implemented which only use little more physical memory than is necessary to store the objects they contain. However, such programs run the risk of running out of virtual address space -- virtual pages unused by the hash table cannot be used by other parts of the program. The main problem with COW at the kernel level is the complexity it adds, but the concerns are similar to those raised by more basic virtual memory concerns such as swapping pages to disk; when the kernel writes to pages, it must copy them if they are marked copy-on-write. COW is also used outside the kernel, in library, application and system code. The string class provided by C++'s Standard Template Library, for example, was specifically designed to allow copy-on-write implementations. One hazard of COW in these contexts arises in multithreaded code, where the additional locking required for objects in different threads to safely share the same representation can easily outweigh the benefits of the approach. The COW concept is also used in virtualization/emulation software such as Bochs, QEMU, and UML for virtual disk storage. This allows a great reduction in required disk space when multiple VMs can be based on the same hard disk image, as well as increased performance as disk reads can be cached in RAM and subsequent reads served to other VMs out of the cache
Thanks Todd, -very informative.
Let me make sure I understand. If I use your snapshot schedule:
snapshot002 at 8:00 - 12:00
snapshot003 at 12:00 - 18:00
snapshot004 at 18:00 - 23:59
I can:
a) do file level restores from any snapshot with admin privileges
b) backup snapshot004 at 00:00 and capture all changes made during that business day
Sound about right?
Thanks!
Yes you will be able to do a file restore from any snapshot with admin rights that you have assigned. To grant access to the snapshot images you select a user in the SMB Snapshot Access fields. Backing up the snapshots from the will capture all changes made after completion of end time of schedule.
Perfectly clear now. Thank you very much.
Ok, sorry, but more clarification is needed.
I set up 4 snapshots so that 002 - 004 do not overlap, and each cover a 3 hour 59 minute window.
I have two issues:
1) The drop-list to select the snapshot for local backup shows no entries (Maintenance/Backup/Local Backup/Snapshot). Why?
Also, if I try to backup without any snapshot selected why does a message pop up saying:
"No snapshot choosed.
Backup can be made only from snapshots with no create- and remove-time assigned."
2) Only the active snapshot actually contains files, the other 3 are empty and designated as "unused"
My goal is to have multiple restore points available concurrently. Is this possible?
It would appear that placing an end time on a snapshot causes it to write to the mail volume and "empty" itself. While this is fine, it is not what I need for my implementation.
The obvious solution is to not put end-times on snapshots, which would cause them to persist for 24 hours until refreshed at the next start time. Sounds great, but when you have more than one snapshot in this mode, I need to know how they interact with each other with respect to writes to the main volume. All the questions I asked previously about interaction still apply.
Thanks in advance for your help.
1)
You must set a Snapshot with no begin and no end time. Then create the snapshot in Maintenance / Snapshot this will set it in manual mode to allow you to select from the Maintenance / Backup.
Please read the instructions on how this is done or read the cut that I have provided.
Function “Local backup”
This function allows you to backup shares into tar-gziped files. Available choices:
Source lv:
Please choose logical volume from which shares will be backed up. It is possible
to backup shares from one logical volumes at once.
When you change source lv, avaliable shares and snapshot will also
change.
Snapshot:
Backup is performed from snapshot to provide data integrity.
You can choose only from snapshots with no create- and remove-time
assigned.
2)
You can have multiple snapshots to provide multiple restore points. Please set your Snapshots appropriate to the scheduled or with no end time for file recovery purposes. It would be best if you can test which Snapshot functions would best fit your needs for this, as every environment is different.
I think I understand snapshots well enough now to know that I want to have no end times in order to preserve restorable data. This gives me snapshots that are refreshed at create time every day. Cool.
The only issue I have now is with backups. You've confirmed that backups can only function on snapshots that have no start or end time. That means no automatically scheduled snapshot can be backed up at all, -only manually created ones.
Is this correct? Seems strange to me.
Thanks.
This is the function of Local Backup. Backup is performed from snapshot to provide data integrity. So you need to have this setup for manual mode for backup and the other Snapshots can be used for quick file retrieval. This is explained in the manual as well.
Simple Question: Is it possible to have more than one snapshot contain data at one time?
Originally I had snap002 - 005 set with create and delete dates, but found that if I wanted to go to their contents *outside* that time range I would find them "unused" and therefore empty.
I cleared the delete time so that they would retain their contents until they are (re)created the next day, but what I am finding is that snap002 gets created and the rest of the snapshots remain "unused."
My goals seem simple enough to me: Multiple CONCURRENT snapshot restore points and a scheduled local backup.
I have already given up on the scheduled local backup because it depends on a manual snapshot creation. Do I also have to give up on the idea of having several snapshot restore points to choose from?
Ironically, I just found out my local backup is working the way I would like; right off the logical volume rather than a snapshot. The UI confused me by putting both drop lists in there and having the snapshot one fail if the snapshot is scheduled.
I am not sure that the backups are actually happening though, as my dynamic volume is full. Is there a cull or overwrite mechanism in place that I can't find?
Yes this function is available to restore but this is a manual process for your snapshots. The Dynamic Volume can be over written.
You are saying that if I manually create snapshots, multiple snapshots can stick around as long as I like, but only one automatic/scheduled snapshot can exist at one time?
Snapshot is a manual restore process. Not sure if we are miss communicating to each other.
Try to provide me in detail what steps you have taken and what are the detail results. These functions are very simple and are easy to test. In future releases we will add more functionality but no time frame is set and details. Thanks for your patients in this matter.
My Goal: Multiple, snapshots available for restore at the same time with these snapshots being created through your scheduling process.
Restore is indeed a manual process, but so far I have only figured out how to have 1 scheduled snapshot contain data to restore at any given time.
I have created them with begin and end dates, and I have created them with only begin dates. In both cases, only one of these automatically created snapshots contains data at a given time.
For me, the value of snapshots is dramatically lessened if I have to create them manually. I would like them to get created on a schedule, and if I need a restore, I pick whichever one is appropriate and perform the restore.
Thanks for *your* patience, I am sure I must be driving you mad with this line of inquiry.
Not a problem on the questions. Allot of this is learning and testing as every environment is different. Even we run tests for many inquiries as there are too many ways to approach desirable results to gain the best possible solution.