Palindrome was acquired Seagate was acquired by Veritas was acquired by Symantec.
Seagate dropped support for Palindrome about a year after acquisition. That was around 1992? We used the Tower of Hanoi / G/F/S rotation scheme. It would give you a total history of any file by browsing to it. You could select a folder (or file) and say restore. It would prompt you as to what tape to insert. It also kept a db of what tapes should be offsite/onsite. Reminded me of CA-11 from the IBM 3090 days. Twas all character graphics! Devin On Fri, Sep 11, 2009 at 4:40 PM, Erik Goldoff <[email protected]> wrote: > like the old Palindrome, used a Tower of Hanoi rotation scheme, restore a > file/folder/system and it would tell you the specific ( and minimum ) tapes > required ... but isn't that basically the predecessor of Symantec's > NetBackup product ? > > > Erik Goldoff > > IT Consultant > > Systems, Networks, & Security > > > ________________________________ > From: Jeff Bunting [mailto:[email protected]] > Sent: Friday, September 11, 2009 2:22 PM > To: NT System Admin Issues > Subject: Re: Restores from Incremental backups > > I think the point was the software (BackupExec, I'm guessing) should be able > to understand incremental restores and not rely on the operator to have to > manually find & select each incremental copy for the restore. I always > thought that was an obvious feature it lacked. Not being able to tell be > how much disk space a restore was going to need was another. > > > On Fri, Sep 11, 2009 at 12:45 PM, Ben Scott <[email protected]> wrote: >> >> On Thu, Sep 10, 2009 at 5:10 PM, [email protected] >> <[email protected]> wrote: >> > I understand the whole differential versus incremental pros/cons. >> ... >> > So, that's why I was wondering about an easier method to restore >> > incremental backups. >> >> If you really understand, why are you looking for something you >> obviously can't do? :-) >> >> Incremental only store the data since the last incremental, so you >> need all the incremental to restore all your data. If you don't use >> all the media you don't have all the data. There's no magic wand that >> re-creates data you don't have (as many people have discovered, much >> to their dismay). >> >> > ... with the files changing in some cases as much as they do, especially >> > the >> > backing up of flat database files, and other things, differentials would >> > hurt us ... >> >> One strategy is monthly full, weekly differential, and daily >> incremental. That way, the worst case is restoring a full, a diff, >> and and four incs, instead of a month worth of incs. >> >> Another strategy is different schedules and rotations for your >> different data sets. Example: Some data that doesn't change often or >> much, but you have a lot of it. Do fulls every few months, plus >> differentials once a week or whatever. Some other data changes every >> day and overwrites old data. Do fulls every day of just that data. >> Etc. >> >> It should in theory be possible to have a backup system that "knows" >> how much data has changed, and automatically does diff or inc based on >> that, but I've never encountered such. Maybe the more expensive >> stuff, like Tivoli. >> >> -- Ben >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > > > -- Devin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
