• Sam Park
    0
    I'm trying to set up the following via CloudBerry.
    > Month, Tuesday, Wednesday, Thursday, Friday: Incremental backup
    > Saturday, Sunday: Full backup

    and.. All plans are going to work through the Command Line.

    My env is.. Cent OS 7.5 and freeware.
    and don't have GUI (Only using Command Line and Web UI)

    Incremental backups are not a problem at all.
    If you create a backup plan by adding Full to the variable,
    > Schedule is not registered normally.
    > There is no verification procedure for the option called Full backup.
    > The syntax I have used is: ./cbb addBackupPlan -n "Backup my docs Full" -a centosAzureBackup -f "/home/sypark/Documents/" -ef "/home/sypark/Documents/books/" -c yes -everyfull week -atfull "12:00" -weekdayfull "mo, tu, we, th, fr" -notification on -useBlockLevelBackup

    Is full backup possible in this situation?
  • Gleb
    34
    Hi , please check out this thread: https://forum.cloudberrylab.com/discussion/474/full-backups-refuse-to-run , the same thing is explained there.

    In a nutshell, our "full" backup is incremental and "block level" backup is block-incremental.
  • Sam Park
    0
    @Gleb Thanks for your comment.
    I thought a full backup from "Cloudberry" would keep backing up the same files every time.
    What I understood from the thread you gave me was that I understood that a full backup would only be done on the first backup and then incrementally backup.
    But I still have questions.
    For example, what are the options like "-everyfull, -atfull"?
  • Gleb
    34
    , that's right, only incremental backup after the first one.

    The options tell CloudBerry Backup to backup Full versions of files on separate schedule, as opposed to Block versions of the same files.
    The other thread refers to this article, please check the Incremental Backup section, it will make it clearer what I mean.

    It is highly recommended to run Full backup once in a while (like monthly Full with weekly Blocks, or weekly Full with daily Blocks) - because do you really want to risk losing the whole subsequent backup of the file if a Block version of it gets corrupted for any reason?
    Disks fail, even cloud storage have a small chance to lose a file (like 0.00000001% for AWS S3, if I'm not mistaken, multiply that by the amount of files in your backup set and it becomes more realistic to lose a single file).
  • Sam Park
    0
    Hi , thanks for your comment.
    I thought a full backup from "Cloudberry" would keep backing up the same files every time.
    As I understand it, I finally understood that "CloudBerry" does not support full backup.
    The full backup I'm talking about here refers to a full backup of the following sites.
    (https://www.cloudberrylab.com/blog/backup-types-explained-incremental-vs-differential-vs-full-vs-synthetic/)

    But I still have questions.
    For example, what are the options like "-everyfull, -atfull"?
  • Gleb
    34
    Hi ,

    These options tell CloudBerry Backup to backup Full versions of files on separate schedule, as opposed to Block versions of the same files.
  • Sam Park
    0
    Hi,
    Thanks to your advice, I started to get a little more acquainted with Cloudberry.
    Finally, in your advice, I don't understand.
    (backup Full versions of files)
    I understand that the version of the file is based on Date.
    Where do the options "-everyfull, -atfull" save when I save all versions of a file? For example, I save three versions based on the date (maximum number of saved versions: 3) and bac up again using the "full" option. After that, I think it is right to have 6 versions, but I can not see it when I test it.

    If you have a link to an academic article on the "full" option, would you share it?
  • Gleb
    34
    TLDR for those who find this thread by search:
    If you don't know which retention policy you need - pick retention by date, and keep retention by number of versions disabled.



    ,

    First of all, you can set one, the other or two rules at once for deleting files - by date and by number of versions.
    If both rules are active, your data can be deleted when ANY ONE rule is satisfied.


    In most cases you want to choose only one rule that meets your business requirements (such as RPO). It is VERY rare you really need both rules active at once - if this is the case for you then you already know why exactly you need this.

    If you don't know which one you need - pick retention by date, and keep retention by number of versions disabled.
    Then, if you decide to use retention by number of versions, please read further.



    "Full version" is 100% of the file.
    "Block version" is xx% of the file, where xx% is how it changed since the previous version of the file.

    In general, you can have a Full version followed by multiple Block versions.
    This is called a chain, because each consequent Block version depends on a previous version, that one depends on its own previous version - and thus back to the Full version which does not depend on anything.

    If you set maximum number of saved versions: 3, CloudBerry Backup for Linux will keep 3 Full versions - and any amount of Block versions in between them.

    For example (let's imagine this is how the file was changing during some time),
    Chain 1: Full - Block - Block
    Chain 2: Full
    Chain 3: Full - Block - Block - Block - Block - Block

    At this point Backup for Linux keeps 3 Full versions.
    When the 4th Full version is created, the 1st Full version and all its dependent Block versions will be deleted from the storage.



    What may be confusing - the behavior is slightly different in Backup for Windows (and most help articles are based on the Windows version).
    Backup for Linux counts only Full versions in retention by number of versions.
    Backup for Windows counts all versions in retention by number of versions (it only deletes the whole chain when it can delete the last version in the chain).

    We in Backup for Linux found this an unnecessary complication and implemented the idea in a simpler and more logical way.
  • Matt J
    0
    What may be confusing - the behavior is slightly different in Backup for Windows (and most help articles are based on the Windows version).
    Backup for Linux counts only Full versions in retention by number of versions.
    Backup for Windows counts all versions in retention by number of versions (it only deletes the whole chain when it can delete the last version in the chain).

    We found this an unnecessary complication and implemented the idea in a simpler and more logical way

    These statements are confusing/conflicting. So according to the first part, Linux and Windows treat versioning differently. But your second statement says you changed it? I'm not sure what you mean by you implemented it in a simpler way. Is this the simpler way? Or it works like the Linux version now?

    So say I have a daily backup setup, 1 full and 6 block levels a week, what would I have to set this to in Windows to keep 3 fulls? 14 versions? Or 20 versions? Or would they accomplish the same thing if all backups ran according to schedule?

    The Linux way makes sense and I assumed that's what it meant in Windows as well but apparently not.
  • Gleb
    34
    , let me try to explain it better. I've also edited the post you refer to to make it clearer.

    What works different: retention of old backups if "Keep number of versions" is enabled.
    What works the same way: everything else.

    So say I have a daily backup setup, 1 full and 6 block levels a week, what would I have to set this to in Windows to keep 3 fulls? 14 versions? Or 20 versions? Or would they accomplish the same thing if all backups ran according to schedule?
    This is exactly why it's implemented in a different way in Backup for Linux. It's hard to understand, and for no good reason.

    In Backup for Windows to have 3 Fulls with 1 Full and 6 Blocks a week you would need to set 20 versions.
    In Backup for Linux you would need to set 3 versions (3 Fulls, basically).
  • Matt J
    0
    This is exactly why it's implemented in a different way in Backup for Linux.

    Ah, you were referring to changing the Linux version. Yes, that way does make a lot more sense. I had assumed that was the way it was supposed to work across the board before seeing your post here.

    Thank you for the clarification.
  • Matt J
    0
    Is there an option in Rebranding to set the default? If so, I could just change that and push out an updated client. All our jobs are using the program default (3). If I could change that in the installer, I wouldn't have to login to 70 systems and change it manually...
  • Matt J
    0
    Nevermind, I found it through the remote deploy options.
  • Gleb
    34
    , yep, Remote Deploy is the best way to go.

    I had assumed that was the way it was supposed to work across the boardMatt J
    We're working on it. Unfortunately, it's not me to make such decisions in Backup for Windows - but with every customer request, including yours, it becomes closer and closer!

    Anyway, my pleasure. If you have unrelated suggestions/questions - feel free to start a new thread or post into an existing one, I try to monitor this Forum daily.
bold
italic
underline
strike
code
quote
ulist
image
url
mention
reveal
youtube
tweet
Add a Comment