Backing up to one disk but can't fit all in because of old files...how to do better?

[michaelcutter]

Hi everyone,

 

Here's the scenario: we are backing up a variety of clients to several file backup sets on a single 320Gb volume. This works just great in some ways because backups and restores are very fast and keep up with our 1Gbit network backbone, and also allow us to do the following: we then back up the file backup sets across a slower network to a tape library in another building, giving us nice, automated, offsite backups, which I just change the tape sets every so often and archive. Then (relying on the tape backups being archived) I can just recycle the hard disk file backup sets every so often when the disk gets too full.

 

However it's very difficult for the tape unit to actually successfully make a backup of the backups, so to speak, as it's trying to pull down (say) 70Gb files when only a few hundred Mb might have changed.

 

Alas File Backup sets can't be split across multiple files - it would be nice if you could say just add a new file much like you might add a tape, then it would only have to back up changes to that file.

 

Does anyone have any thoughts on how I might get around this? Anyone tried something similar to this? I had thought of simply having more backup sets, and making the size of my backup groups smaller (e.g. limiting to 3 or 4 clients per backup set file) but that still just means that the tape unit has to back up the same amount of data each time, it's just smaller files.

 

Although, this may help avoid the problem that while the 2ndary backup is copying the primary, the primary may in fact be busy adding files to the backup set - meaning that the start and end of a file may be different on a backup tape...not good!

 

I've got around this (I hope) by simply scheduling them not to run at the same time.

 

I'd love to find some way to convince Retrospect to do (for instance) a big backup into one file, backed up say once a month, and incrementals into a separate file, which would then be backed up nightly. Does this sound possible?

 

It may be a completely crazy way to do backup but we thought it was worth a go Happy to hear any comments, positive or critical. We're kind of enjoying pushing the boundaries a little here.

 

Cheers,

Mike

[mcswgn]

Quote:

---

I'd love to find some way to convince Retrospect to do (for instance) a big backup into one file, backed up say once a month, and incrementals into a separate file, which would then be backed up nightly. Does this sound possible?

 

---

 

You could try the following, BUT you would need to spend some time thinking about how this might affect the ability to *restore* later.

 

Run two scripts set to backup to different named files. The first set to select everything (except things like cache files or other junk you usually want to skip). The second would include a selector that would only backup files modified after a specific date. The first you would run once a month (resetting the backup first so it is always writing to a new file). After running it you would need to manually edit the selector used by the second script so that the date it is comparing to is the date on which the first script just ran. The second would run nightly and would only backup files newer than those gotten by the first script.

 

To make the right selector, go to Special -> Selectors -> New

After naming the selector, under "Include everything" select Date and then set to:

[File]

[modification date and time]

[is] [on or after]

[fixed date:]

 

and then you would only need to change the date listed each month after running script 1.

 

Instead of "fixed date:" there is also a "file backup" option, but I don't *think* that would do what you want, because usually those things don't look outside the current backup set. That is, the fact that a file had been backed up by script 1 to backup set "Monthly" would be immaterial to script 2 writing to backup set "Nightly". If the file hadn't been written before to "Nightly", then it would be treated as not having been backed up before at all.