Results 1 to 6 of 6

Thread: Incremental Backup Target

  1. #1
    lstroud is offline Active Member
    Join Date
    May 2008
    Location
    NC
    Posts
    25
    Rep Power
    6

    Question Incremental Backup Target

    Whenever I run "zmbackup -i -a all -t /anotherlocation/backup", I get "Error occurred: system failure: Custom backup target is not allowed for incremental backup". How do I run an incremental backup for a different target directory?

    LES

  2. #2
    lstroud is offline Active Member
    Join Date
    May 2008
    Location
    NC
    Posts
    25
    Rep Power
    6

    Default

    bump bump bump

  3. #3
    mmorse's Avatar
    mmorse is offline Moderator
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    20

    Default

    zmprov mcf zimbraBackupTarget /anotherlocation/backup
    zmbackup -i -a all

    Note that if there's no full available at that location it's going to kick off a full instead of an incremental.
    Bug 30513 - allow custom backup target for incrementals

  4. #4
    brian is offline Project Contributor
    Join Date
    Jul 2006
    Posts
    623
    Rep Power
    9

    Default

    You can't change the target for incrementals because an incremental just copies the redologs. The problem this creates is that you'll have out of sync redologs at the normal backup target in the fulls and other incrementals, because of this it's unlikely 30513 will be addressed.
    Bugzilla - Wiki - Downloads - Before posting... Search!

  5. #5
    mmorse's Avatar
    mmorse is offline Moderator
    Join Date
    May 2006
    Location
    USA
    Posts
    6,242
    Rep Power
    20

    Default

    Yup bug 30513 is an extreme outside use case: Say you had no space in backup1, with no freespace to give it becoming available anytime soon, you need to retain old backups, couldn't easily move them to other media (HD/Tape/DVD), and needed another incremental 'right now' - an incremental instead of a full so that you could retain restore-to-time/seq functionality (zmplayredo could be handy here I suppose, but let's pretend that's not how you want to approach it.)

    That's a serious mouthful of a situation to get yourself in (time to monitor your free space proactively).

    If you we're in that pickle right now (without us implementing a --overide or something on the incremental command) you have to copy a full to a backup2 mount that has lots of space, then kickoff an incremental (after adjusting zimbraBackupTarget).

    To make backup1 useful again you'd then need to run a full at the normal target (after clearing up space) else your next incremental to backup1 would be messed up. Plus if you have the room at backup2 you might as well kickoff a full there. Though, yes that changes restore-to-time ability. Really at that point you're better off leaving the zimbraBackupTarget set to to something with plenty of space long term (backup2) else you're running into the same crazy scenario on night 2. If you need to be using backup1 THAT bad it's time to seriously rethink your backup retention strategy (move some old ones elsewhere).

    The other approach to solving the RFE would be a zmbackup incremental --switch with some logic that doesn't remove the redologs from /opt/zimbra/redolog/archive when it rolls them into the backup2, and only copy them instead. (So your next incremental to backup1 would still be ok if you didn't want to adjust the zimbraBackupTarget.)

    But in short, just allowing the -t argument in bug 30513 would be very prone to incorrect usage, and dev time to do it would have little payoff when we could be doing RFE's that are more frequently requested
    Last edited by mmorse; 08-18-2008 at 12:23 PM.

  6. #6
    lstroud is offline Active Member
    Join Date
    May 2008
    Location
    NC
    Posts
    25
    Rep Power
    6

    Default

    For myself, my use case is that I have one backup location that I let run longer but is on the server itself. However, I have another location that I rotate weekly and need to compress to be transported offsite. So, essentially, I am trying to find a good way of copying off the subset of backup files. I can just use find +mtime or parse the file names. However, the -t option seemed like something a little simpler.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 658
    Last Post: 04-04-2014, 09:01 AM
  2. Replies: 2
    Last Post: 09-22-2011, 01:44 AM
  3. [SOLVED] Backups failing, "unable to read metadata for account"
    By smcgrath1111 in forum Administrators
    Replies: 10
    Last Post: 04-10-2008, 03:15 PM
  4. [SOLVED] Changed Backup Target Did Not Change For LDAP
    By rfoster in forum Administrators
    Replies: 4
    Last Post: 11-13-2007, 04:42 PM
  5. Set default backup target for zmschedulebackup?
    By Kirkaiya in forum Administrators
    Replies: 2
    Last Post: 04-11-2006, 02:18 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •