All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Sorry all your data is gone, have a nice day ^_^
Earlier today I received a Love Letter from the service provider on which VPS Price Tracker is hosted. The provider is carrying on some internal migration from SolusVM to VirtFusion—okay that's cool—but not all of their luggage is being hauled over, and some of their customers are receiving the dread Love Letter. Here's mine:
I tried to bribe the employees to please put my luggage in the trunk and let me ride thru the migration, but they wouldn't take my money and instead threw my luggage in the river and shot me in the knee... it still hurts a little:
So now I find myself without luggage and with 200 GB of incremental backups of this VPS stored in my basement, whose network pipe flies at 200 KB/s on a good wind day.
I'm thinking, this VPS has a small 2 GB disk partition containing a bootable Debian ISO image, I can boot off that and take a low-level copy of the VPS disk and dump it somewhere else over the network. That would preserve ZFS on root and the disk partitioning. But then it might be dangerous to restore the disk from that image if the new VPS reprovisioned on VirtFusion has a slightly smaller disk. Oh fuck it.
Comments
200KB/s are you on LoRA? Mars? Venus?
See what happens on a bad wind day!
Have you tried to unclog the pipe?
edit: IPoAC might be an option as suggested before.
How about Starlink?
still using dial up?
Why not installing your new VirtFusion VPS then transfer the data from your old SolusVM to the new VPS? It will be faster than taking the backup to your PC.
probably just in case you decide to nuke the old vm for whatever fuck up you're having now or possibly in the future..
We would not remove the old VM unless the customer requests it after migrating the data.
ZFS on root is required because VPS Price Tracker uses 1.5 million inodes and EXT4 cannot handle it on a 35 GB disk
So I don't think I can take a proper backup myself from within the VPS, that's why I asked support if they could take an external backup of the Qemu image.
It would be cool if you could!
Then you are doing it the wrong way. You should always take offsite backup, we would recommend all our customers to do so. I’m not sure what is missing on the new VPS on VirtFusion here that you can not have the same install/setup as your old SolusVM VPS?
I mean if it's only 35GB you can probably boot into a rescue environment (on both VMs) and do a dd across an SSH connection and write it directly to the new disk (of course size matters...).
If you want to do it "properly": assuming that you do have the a full 35GB of disk on the new VM, use clonezilla to take a disk image from the existing VM to a temporary storage device (hopefully on the same network/low latency so it's fast to copy the image over). Then do the reverse from that image to your new VM.
I'm sure you can request for a temporary VM that has enough storage for your disk image for a short while in case you don't have any other storage options "nearby".
@davide
Is this title accurate?
Exactly, the only caveat is if the new VPS is just 1 byte smaller than the old one, then dd this dick.
Whatever, the website is running off Amazon AWS now due to this mess, I'll eventually find some solution to move it back.
No, move it to offtopic @angstrom, hide it from view, and rename it to "I'm stupid and I don't know what I'm doing ^_^".
SKILL ISSUE.
1.5 million inodes? Is each price record a separate file?
You already mentioned that you have partitionS on the old VM. Should be trivial to resize the non-ZFS partition and get back that lost 1 byte.
It looks like you're really sensationalizing things here including with the title. You're savvy enough to run ZFS on root, you should be able to quite trivially handle this replication not withstanding some minor disk size issues. Plus I'm sure you can request that the disk size be kept the same (or bigger) with Greencloud in case it's a little smaller.
EDITED: Dupe post.
I kinda feel bad for @NDTN having to deal with this over the weekend
Yes I agree with that, it will just sink some hours of time to do this migration manually on my side. If I could pay to have the disk image moved over by the staff I would prefer.
Not just any weekend. A Wedding weekend! And that too on the backdrop of their recent sales thread where I'm sure they're dealing with enough tickets depending on how deals were snagged.
Honestly, with 10Gbps (esp. "intra DC" mostly really fast), asking nicely (actually checking first) to keep the disk sizes the same, that dd should take <15m (I'm being conservative here factoring a consistent 50MB/s network througput!) to finish copying.
Granted there may be some minor tweaks (including network changes) that you've to do post data copying but pre-new-VM-boot, but honestly I don't see it taking "hours" (ordinarily speaking).
Mmm... I think the customers are dealing with this too, on whichever day of the week the provider picked to deal with this. The issue per se can be resolved, it just sinks time that I would have dedicated to other backend work that was scheduled for the day.
bloopers
I have no idea what this thread is about.
Just copy the damn files.
🤣🤣🤣🤣🤣🤣
Minimally, you have a sense of humor, I'll give you that
Clonezilla?
Good news and bad news balanced itself.
The good news is the wedding.
Could you just boot into recovery mode on the new VPS, create the zfs partition, and restore the files from backup?