XenServer NFS Storage Repo in the SMB
-
@Dashrender said:
Well that sure is a simple answer.
LOL - yeah that is kinda a non answer.
Not really. What's the other option? If you don't have enough of something that you need, the answer is always "get more" and/or "find a way to need less." It's really the answer. The question is so simple that it makes the answer seem absurd. But when you look at what the question really is and remove the red herrings, that's all that was asked.
-
@Dashrender said:
I take you the question to be, we planned for 8 TB with backups fitting in an additional 3 TB, 3 months later we found out that was to small. At the point I'd say you have a new project, which is a growth project, and you work it from that angle.
And regardless of what that project is, it's goal will be to "add more storage."
-
@Dashrender said:
@DustinB3403 said:
@scottalanmiller said:
@DustinB3403 said:
If you have limited space and your SR is remote, how does that improve things?
The question isn't if you have limited space with remote SR.
But if you are designing a system and design it with the same amount of storage, you would have the same design decision in either location. If the question is about "what if someone doesn't plan for enough storage" then the answer is "plan for more".
"Plan for more...."
Well that sure is a simple answer.
LOL - yeah that is kinda a non answer.
I take you the question to be, we planned for 8 TB with backups fitting in an additional 3 TB, 3 months later we found out that was to small. At the point I'd say you have a new project, which is a growth project, and you work it from that angle.
Actually no, 8TB today with room for 3TB of growth was the plan for a total of 11TB.
So instead of 11TB you'd want to have 20TB or more local.
-
@DustinB3403 said:
@Dashrender said:
@DustinB3403 said:
@scottalanmiller said:
@DustinB3403 said:
If you have limited space and your SR is remote, how does that improve things?
The question isn't if you have limited space with remote SR.
But if you are designing a system and design it with the same amount of storage, you would have the same design decision in either location. If the question is about "what if someone doesn't plan for enough storage" then the answer is "plan for more".
"Plan for more...."
Well that sure is a simple answer.
LOL - yeah that is kinda a non answer.
I take you the question to be, we planned for 8 TB with backups fitting in an additional 3 TB, 3 months later we found out that was to small. At the point I'd say you have a new project, which is a growth project, and you work it from that angle.
Actually no, 8TB today with room for 3TB of growth was the plan for a total of 11TB.
So instead of 11TB you'd want to have 20TB or more local.
That seems like a lot. Why so much backup?
-
And more importantly, why so much "non-backup" as you are talking about local storage. You still need to move that elsewhere for it to be a backup.
-
@scottalanmiller said:
@Dashrender said:
Well that sure is a simple answer.
LOL - yeah that is kinda a non answer.
Not really. What's the other option? If you don't have enough of something that you need, the answer is always "get more" and/or "find a way to need less." It's really the answer. The question is so simple that it makes the answer seem absurd. But when you look at what the question really is and remove the red herrings, that's all that was asked.
@scottalanmiller said:
If the question is about "what if someone doesn't plan for enough storage" then the answer is "plan for more".
What red herring? If they made a plan, and the plan ended up being wrong, then all you can do is move onto the normal things, as you said, either grow the storage or find ways to use less storage.
I suppose Plan is the red herring in this case. If you plan to little storage, then of course, you should fix the plan and plan for more storage... but I'm sure that the realization that the plan was too small is often after the plan was implemented.
-
@scottalanmiller said:
And more importantly, why so much "non-backup" as you are talking about local storage. You still need to move that elsewhere for it to be a backup.
This I think is the greater question.
If XO is using the SR to store it's backups, is it really a backup? I don't think so - I suppose it could be one of your three, but definitely needs to be on another platform (a different VM host/NAS/cloud/whatever).
-
Is XO looking to move the backup to a different storage target?
-
@Dashrender said:
Is XO looking to move the backup to a different storage target?
Well what happens is it takes an initial backup and sends it to the share. Then it takes a snapshot and compares the differences between the original and the snapshot, then it keeps doing that. So if your VM is completely full, you could have two VHDs that are the same size.
Keep in mind this is only with their delta backup. The normal backups don't do this. This is why I wanted to clarify with @olivier because you could potentially run into an issue without realizing it.
-
I'm slowly starting to come around to @scottalanmiller's idea of buying only what you need now, except in things like storage. There are some things you have to plan for growth. If you plan for too little growth then you have issues. By adding extra cost to your project now, you can prevent headaches in the (quite possibly near) future, that makes it worth it to the IT team in that we won't have to worry that we're out of space yet again. That cuts down on wasteful spending, and time lost restoring backups as you upgrade your storage.
-
@Dashrender It's not! The SR is just here to store a snapshot to make the delta.
But the files are NOT STORED inside any XenServer, but on an external storage (XOA itself or a NFS share). And you can restore the backup even if you lost your whole XenServer infrastructure.
-
@olivier said:
@Dashrender It's not! The SR is just here to store a snapshot to make the delta.
But the files are NOT STORED inside any XenServer, but on an external storage (XOA itself or a NFS share). And you can restore the backup even if you lost your whole XenServer infrastructure.
Ok I have to ask real quick. What's the disaster recovery section for?
Never mind, looks like it copies to a diff pool. I should have read the whole thing first.
-
@scottalanmiller the reason for scaling up to 22TB would be for the time & space it takes to build the delta which is a Snapshot on the Host, until it gets put onto the NFS Server.
Which would then copy it to an External NAS (and with planning another external device like a USB)
3-2-1 Backup.
Live and 2 copies on different media and one off site.
-
@johnhooks To avoid the "re-importing" step that you need with classical backup
Backup:
- exporting somewhere (any filesystem)
- re importing when need (import time)
DR:
- streaming somewhere (another XenServer host)
- ready to start on the target if needed
edit: so it seems similar but it's not for the same use case.
-
@olivier is it a reasonable assumption that you'd want to have at least double the capacity that you're using on the Local Xen SR when building the Delta for that process?
-
So if you plan for 11TB(used/live data) you'd really want 22TB of local storage on the Xen SR for XO to have enough space to perform its function.
-
@DustinB3403 Even classical backup: for a running VM we need to export the snapshot. So if all your VMs are running and you are backuping everything at once, you'll need to double your space usage (at least during the VM export process).
That's why it's important to use thin provisioned storage as possible.
-
And sadly that's nothing we can do about it ^^
-
@olivier said:
And sadly that's nothing we can do about it ^^
Nothing wrong with that, just making sure that the 'plans' are correct.
-
@Dashrender said:
What red herring? If they made a plan, and the plan ended up being wrong, then all you can do is move onto the normal things, as you said, either grow the storage or find ways to use less storage.
The red herring of adding "remote" as if that didn't have the problem and pointing to "what is the LOCAL" isn't enough. But the answer is the same in either case, add more. The implication, the red herring, was this underlying thought that somehow external storage would not run out and local would. But the risk and the solutions are the same.
