My only issue is that only one copy seems to be kept at Crashplan. Yes I have used it. Sometimes the copy on their server gets corrupted, and they depend on you sending a new uncorrupted version in the next backup, after the issue is detected. There have been reports of folks doing a DR Restore, from Crashplan and not being able to because of corrupted files on the Crashplan side. I have even seen this on files backed up to on-site server from clients here (by reviewing logs on the file storage server at my site).
I still use Crashplan, but if Backblaze had a Linux client, I might move there. Back on TSM. It basically does rdist type copies, and keeps copies of the metadata on each file in it's sql language database (kind of DB2 Lite, but not really). Every time you do backups, you need to backup the database and send a copy of it offsite with backups too. I liked keeping an online and an offline (disk, and tape) copy of backups onsite, and 2 copies on tape offsite. We never had enough tape drives or big enough library, so even the on-site tape backup storage pool (group of tapes) were not kept inside the library. It can also use disk drives as storage media, and can handle multiple copies. I worked for one company that modified the TSM schema to use WORM drives to generate backups for both onsite and offsite. The problem was the database kept growing and it had to be dealt with. ><> ... Jack On Mon, May 13, 2013 at 1:50 PM, Iain Morris <[email protected]>wrote: > This may get some chuckles, but I've had decent luck using Crashplan's > free client to back up some small offices with diverse systems to a linux > server. You don't get snapshots over time, but if all you need is an > additional copy for backup, it's quite flexible and open to expansion > offsite for free, or with their seeding service to their datacenter. In > the past I've thought it was too "simple" for a business server environment > (is that bad? :-) ), but it's always in the back of my mind as an option. > > > On Mon, May 13, 2013 at 10:23 AM, Paul Heinlein <[email protected]>wrote: > >> On Sun, 12 May 2013, Skylar Thompson wrote: >> >> On 05/12/2013 10:26 AM, Michael Tiernan wrote: >>> >>>> On Sun, May 12, 2013 at 10:34 AM, Skylar Thompson >>>> <[email protected]> wrote: >>>> > How do you define reliability? >>>> >>> >> I think that that's a darned good question. Skylar's pair of >>>> points misses a key definition. As a guy from Keane that I used to >>>> work with said, no one cares about backups, they only care about >>>> restores. >>>> >>> >> From the customer's perspective -- which for me is the only perspective >> that really counts -- restoration *is* the service; backup is just the tool >> that facilitates it. >> >> I've only had to do about one restoration per year over the eight years >> I've been at $WORK (small engineering-heavy company). >> >> Bacula (+ LTO) has never failed me during that time. I won't claim that >> it's any better than the other tools mention in the OP's list; my point is >> that I've found Bacula to be reliable. (I do agree with the person who >> lamented Bacula's oft-confusing interface and documentation.) >> >> If Bacula's catalog is hosted on traditional hard disks, it can take >> several minutes to build the dump-like interface to the filesystem to be >> restored. I still spool to HDs, but I've moved MySQL to SSDs, and it's much >> much much speedier now. >> >> I've deployed rdiff-backup at home, and on a much smaller scale, but I've >> never done anything but test restores with it. >> >> -- >> Paul Heinlein >> [email protected] >> >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
