BonzaiDuck
Lifer
I'm experimenting and making decisions about a comprehensive approach to my home LAN, workstations, WHS server and backup -- especially, backup.
I use WHS "Win Backup" features through "Computers/Backup" to backup the OS/system/boot disk incrementally and nightly.
I use the same feature in Computers and Backup to run the "client backups" for four systems during the "wee hours."
The server data files are separate from the OS/SystemBootDisk on a StableBit Drive Pool. The categories of these files range from volatile to "static" which means that backups at latter end of the scale need be taken as little as every six months. The categories all fit on 500GB disks.
These things theoretically don't need to be "fast," although I'd imagine it's more taxing to the backup target HDD for running longer with slower transfers.
However -- and I may actually forego doing this as a routine matter -- the "Client Backups" deposited on the Drive Pool in that particular folder are the most volatile in terms of changes to files and dates. It is about 400GB of data.
My tentative backup solution for these data categories is "RichCopy 4.0." I won't explain further, except that any type of imaging software cannot "image" the virtual disk of the pool. And I don't want "duplication" to be reflected in the backup. The Client backups are currently 2x duplicated.
I find that with the "verify" option of RichCopy, the 400GB backup actually takes two days!! All this time, WHS may go through at least one night of "client backups." This could seem to mean that newer client backups would pollute the currency of the backup file set; I'd start copying files dated 1/24/15, but the remainder of the set would come from a "refresh" of 1/25/15.
Yet, I find no inconsistency now between backup and "Client backup folder". I also notice that the backup target shows file dates just prior to the beginning of the backup, even though the date has changed by the time the backup is complete.
Is it possible that StableBit is managing the duplicates during this process? Or perhaps that RichCopy actions through Stablebit are freezing one of the duplicate folders until the copy is complete, while Stablebit would refresh both of the duplicates afterward?
As a backup of backups, my resulting disk needs to be reliable in the rare event I may need it.
I use WHS "Win Backup" features through "Computers/Backup" to backup the OS/system/boot disk incrementally and nightly.
I use the same feature in Computers and Backup to run the "client backups" for four systems during the "wee hours."
The server data files are separate from the OS/SystemBootDisk on a StableBit Drive Pool. The categories of these files range from volatile to "static" which means that backups at latter end of the scale need be taken as little as every six months. The categories all fit on 500GB disks.
These things theoretically don't need to be "fast," although I'd imagine it's more taxing to the backup target HDD for running longer with slower transfers.
However -- and I may actually forego doing this as a routine matter -- the "Client Backups" deposited on the Drive Pool in that particular folder are the most volatile in terms of changes to files and dates. It is about 400GB of data.
My tentative backup solution for these data categories is "RichCopy 4.0." I won't explain further, except that any type of imaging software cannot "image" the virtual disk of the pool. And I don't want "duplication" to be reflected in the backup. The Client backups are currently 2x duplicated.
I find that with the "verify" option of RichCopy, the 400GB backup actually takes two days!! All this time, WHS may go through at least one night of "client backups." This could seem to mean that newer client backups would pollute the currency of the backup file set; I'd start copying files dated 1/24/15, but the remainder of the set would come from a "refresh" of 1/25/15.
Yet, I find no inconsistency now between backup and "Client backup folder". I also notice that the backup target shows file dates just prior to the beginning of the backup, even though the date has changed by the time the backup is complete.
Is it possible that StableBit is managing the duplicates during this process? Or perhaps that RichCopy actions through Stablebit are freezing one of the duplicate folders until the copy is complete, while Stablebit would refresh both of the duplicates afterward?
As a backup of backups, my resulting disk needs to be reliable in the rare event I may need it.
