Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Backup options
05-08-2017, 08:27 AM
Post: #1
Backup options
Hello all,

I have inherited a client with four Drobo B800fs and I'm trying to figure out the best way to have full backups offsite of these units.

Replication is not an option because that doesn't protect you from Ransomware or File Deletion.

What is the community using for versioning file level backups on these Drobo units? Ideally I would like to find a product that can use my large backup server here as a target.
Find all posts by this user
Quote this message in a reply
05-08-2017, 04:10 PM (This post was last modified: 05-08-2017 04:20 PM by Paul.)
Post: #2
RE: Backup options
hi trafalger,
while i have not specifically needed to do versioning, i have used some tools from the syncback range of software (on windows), for several different methods of backing up data from computer to drobo, or drobo to computer, or DAS drobos to drobos and it works very well.

some tools i think are free, and syncbackse does support versioning and should be able to support networked/nas models. (im always recommending syncback for windows users, though i didnt do versioning, but if you are on windows, it might be worth trying out some of the tools with a smaller copy of some data, just to be happy with the way it works before automating anything)
here is a copy and paste of one of the help pages to do with versioning below for you in case handy:

(one thing to bear in mind though, is that if versioning is enabled and large files are modified often, it may require more space or use up more space where the versions are stored, and if this is on a drobo, it is always good to make sure that the overall drobo is not overfilled, and probably best not to go past the 94% used mark, also for performance)

"
Expert Mode: Copy/Delete, Versioning



For a description of versioning see the section What Is Versioning below. Versioning cannot be used (on the destination) when compressing to a single Zip file, or when doing a backup to an email server.



· Enable versioning on source/left/destination/right: If enabled, versions of files will be kept in that location. You can, for example, choose to only keep versions in the destination/right.



· Where versions files are stored...: This setting defines where the versions files are kept. They are either kept in a sub-folder of each folder, or kept within a folder in the source/destination. Once you choose a setting it is not recommended that you change it otherwise you will no longer have access to your versions.



· Keep a maximum of x versions: The number of versions of a file to keep can be specified here. Note that obviously the more versions of files you keep the more disk space will be used. When the profile is next run it will automatically delete any excessive versions (starting with the oldest version). If the value is set to zero then versions are never deleted based on the number of versions.



· Keep versions for a maximum of x days: When a version of a file is made the date & time when the version was made is recorded. Note that this is not the last modification date & time of the file, nor is it the creation date & time of the file, it is the date & time when the version was made. Using this option you can specify how long a version should be kept. Once the version is older than the specified number of days it is automatically deleted when the profile is next run. If the value is set to zero then versions are never deleted based on their age.



· Change Filter: When this button is clicked you can choose what types of files are versioned or not. The filter applies to versions on the source/left and destination/right. For example, entering *.exe and *\temp\* in the "Files NOT to version" field will not version any EXE files, or any files in sub-folders called \temp\.



Versioning is available in Expert Mode and is associated with the Copy/Delete settings.



What is versioning?



A version of a file is automatically created when:



· A file is to be replaced (a copy of the file to be replaced is made before it is replaced)



· A file is to be deleted (a copy of the file to be deleted is made before it is deleted)



· A file is to be moved (a copy of the file to be moved is made before it is moved, which is essentially the same as being deleted)



Assuming versioning is enabled, here are some examples of how it works:



· You choose to delete a file. SyncBackSE makes a version of the file and then deletes the file. At a later time you may decide that you actually wanted to keep that file. If so you can run the profile and retrieve the version and so restore the file.



· You make some modifications to a document then make a backup of it. SyncBackSE will make a version of the backup file that is about to be replaced then make the backup. At a later time you may decide that you did not want those changes. If so you can run the profile and retrieve the version and so restore the file to before the changes were made.



Where are the version files kept?



Where the versions files are kept depends on the choice you made:



· In a hidden sub-folder of the folder that contains the original file: The versions of files are kept in a special hidden sub-folder called $SBV$. Each folder will have this special sub-folder if there any versions of files in that folder. SyncBackSE will automatically mark the folder as hidden when it creates it. You should not rename the folder or the files inside it otherwise the versions files cannot be used. You are free to delete the folder and the version files in it (you will obviously lose those versions) but it will not affect SyncBackSE as no database of those versions files is kept (it is always built at profile run time).



· In a hidden sub-folder of the base folder: The versions of files are kept in a special hidden folder called $SBV$ which is in the base folder. For example, if your destination directory is X:\My Backup\Documents\ then the versions folder will be X:\My Backup\Documents\$SBV$\. You should not rename the folder or the files inside it otherwise the versions files cannot be used. You are free to delete the folder and the version files in it (you will obviously lose those versions) but it will not affect SyncBackSE as no database of those versions files is kept (it is always built at profile run time).



When deciding where to keep the versions files, please consider the following:



· In a hidden sub-folder of the folder that contains the original file: If you have more than one profile that is using the same folder, and is using versioning, then the advantage of choosing this option is that all the profiles will have access to the same versions. Another advantage is that you can change the base folder and not lose the versions (as long as they are still sub-folders). The disadvantage of choosing this option is that it becomes impossible for SyncBackSE to know if a directory is truly empty or not. For example, if there are versions of files in the folder, but no actual files (e.g. they've all been deleted), then SyncBackSE does not know if the folder should be left empty of whether it shouldn't exist. This has implications for SmartSync profiles as it may cause empty folders to be created on the opposite side when you don't want them.



· In a hidden sub-folder of the base folder: The advantage of this option is that it removed the "empty folder" issue. This is because the versions are not stored in a sub-folder of the actual folder, so the actual folder can be deleted without affecting the versions. A disadvantage of this option is that the versions folder is pinned to the source/destination folder, so if you change the source/destination folder then you lose the versions. Also, if more than one profile is using the same folders then they will not share the versions (unless the source/destination path is the same).



Changing where to store the versions will result in losing those versions.



How to restore versions



Versions can be restored from the Differences window (or from the File Collision window). When a profile is run as a Restore, and versioning is used, the Differences window will automatically show skipped files. This allows you to restore old versions of files that no longer exist, and restore versions of files where there is no change.



If you wish to restore versions without using Restore (e.g. you are using a SmartSync profile and so cannot run it in Restore mode) then select the profile in the main window, hold down the Ctrl key, keep it pressed, then click the Run button. This will ensure the Differences window is shown. You then need to enable it to show skipped files (click the bar at the top of the Differences window to see the options).



See the Differences help page for details on retrieving versions of files.



Frequently Asked Questions



Q: Can versioning be used with Fast Backups?

A: Yes, but it can greatly reduce the performance gains you get with Fast Backup. If your profile is configured to display the Differences window then it is recommended you switch off this option as displaying the Differences window forces SyncBackSE to scan every folder to see which versions are available for each file.



Q: Can versioning be used with SmartSync profiles?

A: Yes.



Q: Can versioning be used with single zip files?

A: No.



Q: Can versioning be used with email servers?

A: No.



Q: What if I switch from not using compression to compressing each file into its own zip file (or vice-versa)?

A: You will be warned that you can no longer use the existing versions. This is because if compression is used then the old versions are also stored compressed (and encrypted, if configured so). If no compression is used then the versions are not stored compressed.



Q: What if I switch off versioning? What happens to the versions files?

A: If a profile does not use any versioning (on the source/left or destination/right) then the old versions files will be treated like any other kind of file. If you were using versioning on both the source/left and destination/right, and then switched off versioning on one side, then the old versions on that side are ignored. For example, if you had versioning on the source/left and destination/right, and then switched off versioning in the source/left, then the old versions files in the source/left will be ignored, i.e. SyncBackSE will pretend those files do not exist.



Q: What if I change where versions are stored? What happens to the versions files?

A: You will lose access to the existing versions. You must manually delete the versions files, or configure your profile to ignore the $SBV$ folders.



Q: Are the versions stored compressed or encrypted?

A: Only if the files themselves are.



Q: Why aren’t the versions stored compressed?

A: Because it would slow down the profile considerably.



Q: What if I decrease the number of versions to keep, or how long they are kept?

A: When the profile is next run any excess versions will be automatically deleted.



Q: Can I choose to store the versions in a directory I choose?

A: No.



Q: What if I change the source/left and/or destination/right path? Are the versions files automatically moved?

A: No (this is the same as using variables).



Q: What if I used variables in the source/left and/or destination/right path?

A: If versions are kept in a sub-folder of where the original file actually is, then using variables has no effect, except obviously the versions files will be scattered across various folders based on the variable values.



Q: If a folder is filtered out (or unselected) does SyncBackSE still manage the versions in that folder?

A: No, because the profile is specifically configured not to use that folder.



Q: If a file is filtered out (or unselected) does SyncBackSE still manage the versions in that folder?

A: Yes. When looking at file versions it ignores any filtering or selection rules. This makes sense because the original file may no longer exist anyway, for example.



Q: Does versioning affect performance?

A: Normally it has a very small effect on performance. SyncBackSE has been developed to make versions as quickly as possible. However, there are cases where a version cannot be made quickly (i. e. the file to be replaced or deleted has to be copied, instead of being moved, in which case it can affect performance if the file is large).




Note that if you are using Fast Backups then enabling versioning on the destination can greatly reduce the performance gains you get with Fast Backup.




Q: My log file has the error “The profile "profile name" was automatically disabled: reason why disabled.” What do I do?

A: What happened is that a version of the file was made (i.e. it was moved into the versions sub-folder, called $SBV$), but the copy failed. SyncBackSE then attempted to move the file back from the versions sub-folder to where it was originally. However, something went wrong and the file cannot be moved back. You must manually move the file back from the $SBV$ folder to its parent folder and rename it. Once done you should re-enable the profile via the main window (right-click on the profile and select Enable from the pop-up menu). This situation is extremely unlikely to happen.

"

(btw i have XP home SP2, a Drobo v1 with 2x 1TB/2x 1.5TB WD greens, & a bkp Drobo v2 with the same + a DroboShare: unused)
& a DroboS v2 with 3xWD15EADS &2x1TB in DDR mode on win7, & a drobo5D (all usb)
  • btw i did a sustained (write) operation for about 6 hours, and got 13.2MB / sec ...objection? "sustained" :)
    (16.7MB/s on a v2 & 47-96MB/s drobo-s)
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: