New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
No, PEBCAK!
I will either go with
ddortar - | sshdepending on how low-level the backup restoration will be, either I'll move the data at file level or at FS level. I haven't thought of the details yet, in the afternoon I'll sit at the big desk computer and figure out what are the constraints and what is the most efficient way of restoring the data.https://lowendtalk.com/discussion/158771/which-providers-offer-ipoac-for-pigeons
That's why I keep a 2 GB disk partition with a bootable Debian image on this VPS, because booting from a recovery ISO is not possible on GreenCloud. I shall figure out all the needful when I'll sit at the computer later today.
Only if you spend time to make fail-over-server in case of @NDTN servers caught in drone strike. Though, the LES proposed widget is cute
On VirtFusion, there is a nice recovery mode that works well, and you can mount an ISO to boot from, as well. The new VPS you're moving to should have that.
is that me
i can't control evil larry
No one can control him, hide your peeners
Hey thanks for that! Failover is totally manual still and it takes about an hour to restore a minimal working service without all the background processes running. Not a big deal frankly as this is a hobby / pet project in the whole.
Will check on that.
According to GreenCloud's email, the old VM would be nuked contextually to the provisioning of the new one, there would never be two VMs existing at the same time. And I'm only given 1 IPv4 address, how would you stretch it to two VMs? @NDTN your staff / email don't mention this, how would you do it?
What are you doing with 1.5 million inodes? Are you storing each individual piece of data as a separate text file? Maybe it's time to use Postgresql?
DB is for Wuss
I'm also curious how you're at 1.5m inodes; my media server is only ~623k inodes at 22TiB.
Need to think out of the box
Are we even reading the same email?
No exactly ahah I noticed that but a bit late. I'm restoring the data over an external backup anyway to avoid the risk of premature termination, they say 2/3 days max until termination but I'd rather play it safe, and I'll hold a binary image of the disk on Amazon AWS for some time afterward just in case they throw a hand grenade to the shit-stained fan.
Currently restoring a filesystem-level backup since the new storage is large enough to hold the whole binary image of the old VM as-is, so I won't have to deal with any upper-level complexities.
My 256GB MicroSD uses 448K inodes at 40% usage
Ask Claude to do it for you.
The database is custom made, it uses a single sqlite3 file of ~800 MB to store the data at rest, and serves search queries from preloaded memory indexes that are read at boot. It's cool because by having full control of the algorithms it can XOR bitsets to determine if a stored record matches a search query and pack the data without wasting memory.
What consumes those many inodes is the long-standing dependency of VPS Price Tracker on RRD files, this was a design decision from back when the project was still called PonyHost, it was primarily meant to be cute and small, and not meant to scale 100x to its current size. There is one RRD file for each VPS and dedicated server configuration, each multiplexing price and stock data. These RRDs package ~3 KB of data per file and there are ~1.2 millions of them. They are highly compressible with Huffman encoding (ahah that should be AffMan encoding
) since price and stock data change infrequently over time and a data dictionary can represent repetitions with less entropy than a plain RRD, so I'm considering packaging multiple RRDs into aggregate files and having a common dictionary for each pack. The same is already implemented for storing the URLs linking to the checkout pages, as they are generally similar to each other (only the PIDs at the end of the URLs change) and they are also about a million.
You forgot the wedding
@davide i would advise you to get the cheapest possible storage box you can find. Atm i can see 500gb from hostbrr in Utah is available for 7 buck per year. Thats 3/4 your coffes, and keep it for backup. That way you can do fast backups with high speeds.
Believe it or not I'm an AWS trial plan free for 6 months! They must have forgotten about me because I already used their free trial a couple of times already!
And its gone insert southpark
That sounds like a lot of work for microseconds. You could keep the entire dataset in memory with Pg and use various indexing strategies and I am skeptical you'd really see a huge difference. Pg may even be faster. In a world where a 4GB VPS is $5/month, how critical really is "wasting memory"?
If it was me, I'd spend an afternoon to vibe-code a utility that exports all that data into Pg.
It's only ~33.5GB of data, which is not at all huge for a database these days. And it's a lot easier to manage than 1.2 million files. It would also probably save you disk space since there's not all the filesystem metadata and wasted space since your ~3Kb files probably aren't uniformly in 512-byte blocks.
But...party on, you crazy diamond.
69 kB/s
"Man of Culture" certified newtork.
Damn bro, damn
I do get the trillion things your VPS does, but, ZFS in A VM that is most probably on ZFS is........... bad ( over HW raid is even worse )
Did you try XFS? yet that handles large files not trillion small ones......
More RAM???
PS: need a backup server?
PSS: try bribe money again, might work on the second try.
Oh man, now all the important people are posting in here!!