I'll add a cautionary note here. We do a rotation that we manage ourselves. Mostly because the differential and full backups are a little different. We've got 5 2-bay USB chassis. On 1 drive we have 4 folders for Mon - Thu. The other drive has one folder for the full on Friday. Each Monday we swap the entire chassis.
To do this we need to stop the tape engine, stop the USB device, swap the USB chassis, and restart the tape engine. The tape engine song and dance is needed to close the open pointers to the FSD.
When we connect the new USB chassis we need to go back into the device groups and reassign all the folders to the proper group. It would be nice if the program (R12) would remember that we told it that all the folders on E: are in PGRP0, the folder on F: is in PGRP1 and so on. Instead, each folder is in it's own PGRP. I've tried setting my job destination as any PGRP that has a media from the proper pool to avoid this step but it doesn't seem to work. Someday I'll address this issue with CA.
Other than needing a few minutes of care each Monday morning (and the last Friday of the month for a monthly dump) the FSDs work fine.
The USB chassis are hot swappable. I haven't tried this but suspect it would be a problem since Arcserve keeps file handles open and that's not a good time to swap a drive.
Here's what we do here. We've got 11 FSDs. 4 of these are used for an incremental on Monday - Thursday. 5 of these are used for a full backup of the accounting system that is done each weekday. There is one for a full backup on Friday and one for a full Monthly backup on the last Sunday of the Month. We don't use a rotation to manage this. We do have media pools setup for the FSDs.
Each FSD is a folder on a USB attached enclosure. Each Monday we swap the enclosures for the E and F drives. There's a little bit of annoying work to do this.
They are setup as follows:
E:\INCR_A .. E:\INCR_D (4)
E:\ACCT_A .. E:\ACCT_E (5)
F:\FULL (1)
G:\MONTHLY (1)
Each type of backup is a separate job.
This may not be the optimal way but it works. If the list of files to backup changes you need to modify more than 1 job.
I can't say I've ever heard of a linkstation. We have the same issue (that's pronounced problem) here with our linux servers. The way we got around this was to setup a filter for each server. We only include files modified in the past 3 days. The arcserve concept of days is not what I expected. This means that 3 days is not 72 hours but is 3 calendar days. Tonights' backup will include anything modified starting Friday at 00:00:00 and ending tonight 23:59:59. You can set your threshold to whatever size you like. Ours works like this
Day of Backup Files Covered
Mon Fri - Mon
Tue Sat - Tue
Wed Sun - Wed
Thu Mon - Thu
Therefore, anything modified on Friday ends up on the full weekly dump and the first differential/incremental of the next week. It's not ideal but it works.
Buffalo Linkstation - NAS drive. They aren't formatted by NTFS though - they have their own format (XFS). Its possible that the archive bit is affected by this non-standard format. I have read elsewhere of issues with Arcserve incrementals backups on Samba, so its probably all linked.
I'll have a look at your suggestion about filters and give it a try - its a bit poor though that we have to resort to these methods - Arcserve should be able to do something as basic as incremental backups!
Linux doesn't have archive bits either and for years, make that decades, the way around this was external control files. If the modify date is newer than the last backup date then add this file to the backup. It's not a hard concept. Linux has multiple backup levels so there's an extra step or 2 in deciding what to include.
I agree that the agent could do a better job of managing it.
The filters let you set thresholds but the default should support differential/incremental jobs.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.